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(54) Digital data copyright protection system 

(57) A digital data copyright protection system 
especially for unencrypted data to protect a copyright 
thereof while charging a user appropriate royalties 
therefor. In the digital data copyright protection system, 
super distribution data is received by a super distribu- 
tion data receiving unit (401) for storage in a super dis- 
tribution data storage region (402). Right management 
information is acquired by an RMI acquiring unit (403) 
for storage in an RMI storage region (404). Unencrypted 
data is read by a data reading unit (406), encrypted by 
a data encrypting unit 408 with a key extracted by a con- 
tent key extracting unit 405, and then is provided with 
the right management information in an RMI adding unit 
(409) for storage. Once the data is through with a pur- 
chase processing in a purchase processing unit (412), 
the data is decrypted by the content decrypting unit 

(414) , and is played back by a reproduction control unit 

(415) and a speaker (416), or provided with an ID stored 
in a user ID storage region (418) by a distributor ID add- 
ing unit (411) for output. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention 5 

[0001] The present invention relates to digital data 
copyright protection systems and, more specifically, to a 
system for protecting a copyright of music data while 
charging a user appropriate royalties therefor. w 

Description of the Background Art 

[0002] In recent years, CDs (Compact Disc) have 
been popular media for music. Such CD is easy to carry, 15 
and thus people feel free to hand their CDs to others to 
let them try. Such hand-to-hand music distribution often 
contributes to mega hit. Problem herein is that the CD is 
hardly protected against piracy, that is, unauthorized 
copying. Further, such CD is copied with ease into a 20 
CD-R (Compact Disc Recordable) which recently 
became commercially available. MDs (Mini Disc) are 
also becoming popular as media for music data previ- 
ously recorded in the CDs. Music data is thus easily 
copied thereby, and if the music data is shared beyond 25 
the scope of the copyright law, the copyright holders suf- 
fer. 

[0003] In order to prevent such easy copying, dis- 
closed in Japanese Patent Laid-Open Publication No. 9- 
34841 (97-34841) is a conventional system for encrypt- 30 
ing CDs before distribution, transmitting a decryption 
key over a network, and billing therefor. As such, online 
music distribution and billing over the network is quickly 
becoming popular. 

[0004] With such conventional system, however, 35 
online music distribution and billing is personalized one- 
on-one, and thus music data is not expansively distrib- 
uted among users as with the hand-to-and distribution 
workable for CDs. So far, facilitating the distribution of 
music data has not been an issue for online music dis- 40 
tribution. 

SUMMARY OF THE INVENTION 

[0005] Therefore, an object of the present invention 45 
is to provide a copyright protection system especially for 
online music distribution, implementing protection for a 
copyright of music data by charging appropriate royal- 
ties therefor, and facilitating the distribution of the music 
data. 50 
[0006] The present invention has the following fea- 
tures to attain the object above. 

[0007] A first aspect of the present invention is 
directed to a digital data copyright protection system for 
charging a user appropriate royalties while protecting a 55 
copyright of digital data, the system comprising: 

a content distribution unit operable to distribute 



super distribution data including the digital data 
over a network: 

a plurality of digital data recording and reproducing 
apparatuses interconnected via the network, each 
capable of storing the super distribution data 
received from the content distribution unit, repro- 
ducing the digital data, and distributing the super 
distribution data stored therein to the others; and 
a billing processing unit operable to communicate 
with the digital data recording and reproducing 
apparatuses over the network, and go through a 
billing processing for charging the royalties, 
wherein 

the digital data recording and reproducing appara- 
tuses each 

communicate, prior to reproducing the digital 
data, with the billing processing unit to go 
through a purchase processing to be ready for 
the billing processing when receiving the super 
distribution data from the content distribution 
unit or the other digital data recording and 
reproducing apparatuses over the network, 
and 

add, prior to distribution, a distributor ID to the 
super distribution data received from the con- 
tent distribution unit or the other digital data 
recording and reproducing apparatuses over 
the network, wherein, 

when the super distribution data subjected to the 
billing processing is provided with the distributor ID, 
the billing processing unit goes through a bonus 
processing with respect to a user identified by the 
distributor ID. 

[0008] As described above, in the first aspect, pro- 
vided is a digital data copyright protection system capa- 
ble of protecting a copyright while charging a user 
appropriate royalties, and benefiting a copyright holder 
to a greater extent by using bonus to lure the user to dis- 
tribute the data. 

[0009] A second aspect of the present invention is 
directed to a digital data recording and reproducing 
apparatus being capable of storing super distribution 
data including a content which is digital data encrypted 
under a first system and right management information 
having a content key used for the first system, and of 
reproducing the content after going through a purchase 
processing to be ready for a billing processing by com- 
municating with a billing processing unit connected via a 
network, the apparatus comprising: 

a super distribution data receiving unit operable to 

externally receive the super distribution data; 

a super distribution data storage unit operable to 

store the super distribution data; 

a purchase processing unit operable to go through, 
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in response to a user's instruction, the purchase 
processing to reproduce the content included in the 
super distribution data stored in the super distribu- 
tion data storage unit; 

a data extracting unit operable to extract the super 
distribution data from the super distribution data 
storage unit; 

a content decrypting unit operable to decrypt, when 
the purchase processing is carried out, the super 
distribution data stored in the super distribution 
data storage unit under the first system, and extract 
the content; 

a reproduction unit operable to reproduce the con- 
tent extracted by the content decrypting unit; and 
a distributor ID unit operable to encrypt a first user 
ID which is identification information unique to the 
apparatus, and add the encrypted first user ID to 
the super distribution data extracted by the data 
extracting unit for external output. 

[0010] As described above, in the second aspect, 
provided is a digital data recording and reproducing 
apparatus capable of charging a user appropriate royal- 
ties and accordingly protecting a copyright by distribut- 
ing super distribution data including content such as 
music. 

[0011] A third aspect of the present invention is 
directed to a billing processing unit operable to store 
super distribution data, and from a digital data recording 
and reproducing apparatus capable of reproducing a 
content after a billing processing, receive, over a net- 
work, billing control information corresponding to the 
super distribution data, a distributor ID indicating who 
has distributed the super distribution data, and a trans- 
mitter ID corresponding to the digital data recording and 
reproducing apparatus, the billing processing unit com- 
prising: 

a billing processing information receiving unit oper- 
able to receive the billing control information and 
the distributor ID; 

a transmitter authorizing unit operable to receive 
the transmitter ID and identify a transmitter; 
a billing processing unit operable to carry out, 
according to the billing control information received 
by the billing processing information receiving unit, 
the billing processing with respect to the transmitter 
identified by the transmitter authorizing unit; and 
a bonus processing unit operable to carry out a 
bonus processing for a distributor identified by the 
distributor ID received by the billing processing 
information receiving unit. 

[0012] As described above, in the third aspect, pro- 
vided is a billing processing unit capable of protecting a 
copyright while charging a user appropriate royalties, 
and benefiting a copyright holder to a greater extent by 
offering a user identified by a distributor ID bonus to lure 



him/her to distribute the data. 

[0013] These and other objects, features, aspects 
and advantages of the present invention will become 
more apparent from the following detailed description of 
5 the present invention when taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 [0014] 

FIG. 1 is a block diagram showing the structure of a 
digital data copyright protection system according 
to a first embodiment of the present invention; 

15 FIG. 2 is a schematic diagram showing the configu- 
ration of first super distribution data; 
FIG. 3 is a schematic diagram showing the configu- 
ration of second super distribution data; 
FIG. 4 is a schematic diagram specifically showing 

20 how a user distributes, to other users, super distri- 
bution data which he/she had received under the 
present copyright protection system; 
FIG. 5 is a block diagram showing the structure of a 
digital data recording and reproducing apparatus of 

25 the first embodiment; 

FIG. 6 is a schematic diagram showing a first digital 
data recording and reproducing apparatus 1011 
implemented by a general computer; 
FIG. 7 is a flowchart showing the operation of the 

30 digital data recording and reproducing apparatus 
for acquiring right management information; 
FIG. 8 is a schematic diagram showing the struc- 
ture of a right management information managing 
table; 

35 FIG. 9 is a schematic diagram showing the struc- 
ture of super distribution data management infor- 
mation 1605; 

FIG. 10 is a flowchart showing the operation of the 
digital data recording and reproducing apparatus 

40 for reproduction; 

FIG. 11 is a block diagram showing the detailed 
structure of a distributor ID adding unit 41 1 ; 
FIG. 12 is a block diagram showing the detailed 
structure of a purchase processing unit 412; 

45 FIG. 13 is a schematic diagram showing an exam- 
ple of billing processing information; 
FIG. 14 is a flowchart showing the operation of the 
digital data recording and reproducing apparatus 
for purchase processing; 

so FIG. 15 is a block diagram showing the detailed 
structure of a billing processing unit 801 ; 
FIG. 16 is a flowchart showing the operation of the 
billing processing unit 801 for the billing processing; 
FIG. 17 is a block diagram showing the structure of 

55 a digital data recording and reproducing apparatus 
according to a second embodiment; 
FIG. 18 is a diagram showing the structure of an 
SDAF package according to a third embodiment of 
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the present invention; 

FIGS. 1 9a to 1 9c are diagrams showing other struc- 
tures of the SDAF packages; 

FIG. 20 is a diagram showing how to split an SDAF 
title into SDAF packages; 

FIG. 21 is a diagram showing an example of the 
SDAF package; 

FIG. 22 is a diagram showing a header structure; 

FIGS. 23 and 24 show source codes describing the 

header structure using the C++ language; 

FIGS. 25a to 25c are diagrams showing how to 

define a CEL attribute table using a tag structure; 

FIG. 26 is a diagram showing a correspondence 

between key pairs and CELs; 

FIG. 27 shows source codes describing the key pair 

structure using the C++ language; 

FIG. 28 is a diagram showing how to refer to the 

CEL from navigation data; 

FIG. 29 is a diagram showing an example of the 

structure of the navigation data; 

FIG. 30 is a diagram showing an another example 

of the structure of the navigation data; 

FIG. 31 is a table showing specifications of 

MPEG2-AAC applied to an audio CEL; 

FIG. 32 is a table showing specifications of JPEG 

applied to an image CEL; 

FIG. 33 is a table showing specifications of MPEG- 
I frame applied to the image CEL; 
FIG. 34 is a table showing specifications of PNG 
applied to the image CEL; 

FIG. 35 is a table showing specifications of MPEG2 
applied to a video CEL; 

FIG. 36 is a diagram showing the structure of a time 
search map; 

FIGS. 37, 38a, and 38b are a table and diagrams 
showing a header included in the time search map 
in detail; 

FIG. 39 is a table showing each entry included in 

the time search map in detail; 

FIG. 40 is a table showing an example of CEL redi- 

rectors; 

FIGS. 41a to 41c are diagrams showing examples 

of how to distribute the SDAF package; 

FIGS. 42a to 42c are diagrams showing examples 

of how to create the SDAF package; 

FIG. 43 is an external view of a portable music 

player; 

FIG. 44 is a block diagram showing an example of 
the structure of the data conversion unit; and 
FIG. 45 is a block diagram showing another exam- 
ple of the structure of the data conversion unit. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

(First Embodiment) 

[0015] With reference to FIGS. 1, 2, and 3, 



described below is a digital data copyright protection 
system according to a first embodiment of the present 
invention. FIG. 1 is a diagram showing the structure of 
the digital data copyright protection system. 
5 [0016] The digital data copyright protection system 
includes first to third digital data recording and repro- 
ducing apparatuses 1011 to 1013, a content server 102 
for distributing digital data, and a billing server 103 for 
going through a billing processing. These are intercon- 
10 nected via the Internet 104. Herein, the Internet is not 
restrictive, and may be a telephone line, dedicated net- 
work, satellite broadcast network, or CATV network. 
The number of digital data recording and reproducing 
apparatuses is not an issue here. 
15 [0017] In FIG. 1 , the first to third digital data record- 
ing and reproducing apparatuses 1011 to 1013 are typ- 
ified by personal computers connected to the Internet. A 
user receives digital data through the Internet or from 
media such as music CDs for reproduction on his/her 
20 digital recording and reproducing apparatus. 

[0018] FIGS. 2 and 3 are diagrams exemplarily 
showing the configuration of the digital data distributed 
through the Internet. The digital data in FIG. 2 includes 
right management information 203 and a content 205. 
25 The right management information 203 includes billing 
control information 201 and a content key 202. The con- 
tent 205 is composed of one or more pieces of audio 
data 204. Hereinafter, such configured digital data is 
referred to as first super distribution data. 
30 [0019] The billing control information 201 includes 
information as to a bill for the content, availability for pre- 
viewing, the number of previewing, and the like. The bill- 
ing control information 201 may also include information 
as to a billing arrangement which is based on the 
35 number of listenings, i.e., for every listening or a prede- 
termined number of listenings, and the number, for 
example. The content key 202 is used to encrypt and 
decrypt the content 205. The content 205 is previously 
encrypted by the content key 202. 
40 [0020] The right management information 203 is 
previously encrypted under a predetermined encryption 
system with a key different from the content key 202. 
Such key is called a right management information key 
(not shown), and is typically stored in software operable 
45 in the first to third digital data recording and reproducing 
apparatuses 1011 to 1013. The software is installed by 
the user for use. Herein, the right management informa- 
tion key may encrypt and decrypt the information in 
hardware dedicated therefor. 
so [0021] The right management information key is 
stored in a region where no user is accessible with nor- 
mal operation. Such region inaccessible by the user is 
hereinafter referred to as secured region. Here, the 
secured region is often provided in a built-in storage in a 
55 general computer device, but may be in dedicated hard- 
ware, storage, or storage medium. 
[0022] The digital data in FIG. 3 includes a user ID 
301 and first super distribution data 302 as shown in 
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FIG. 2. Such configured data is hereinafter referred to 
as second super distribution data. 
[0023] The user ID 301 in FIG. 3 indicates informa- 
tion for identifying the user having the digital data dis- 
tributed to another. The user ID 301 is encrypted under 5 
a predetermined encryption system, and is uniquely 
provided to every user. The user ID 301 is stored in the 
above-described secured region, and may be com- 
posed of several user specific IDs. The specific user ID 
is generated at installation of such software as above in w 
the copyright protection system, or provided from the 
billing server 103 or others over the network. Details 
about the possibility of the user ID 301 being composed 
of several specific user IDs are left for later description. 
[0024] A CD (external recording medium 417, 15 
which is later described) in this embodiment includes a 
content (music data) and content identification informa- 
tion for identifying the content. The content identification 
information is typified by a code called ISRC (Interna- 
tional Standard Recording Code) used to identify a 20 
music title. 

[0025] The content recorded on the CD is presuma- 
bly not encrypted. The CD herein may be an Enhanced- 
CD in which a region for music CD (CD-DA) and a CD- 
ROM region are combined. Further, the CD-ROM 25 
region therein may store the right management informa- 
tion 203 encrypted under a predetermined encryption 
system. 

[0026] Described below is digital data distribution 
under the present copyright protection system. Assum- 30 
ing that, with the first digital data recording and repro- 
ducing apparatus 1011, a user A purchases and 
reproduces some digital data (typically music), and 
he/she finds himself/herself liking the data and decides 
to suggest a user B to purchase the data. In such case, 35 
the user A may store the digital data in a storage 
medium and hand it to the user B, or directly transmits 
the data via the Internet. This works well for both of 
them since the user A is not bothered to describe what 
the digital data is like (e.g., title of the music, name of 40 
the singer), and the user B merely receives the data 
from the user A. Afterward, the user B may also find 
himself/herself liking the music, and recommend it to 
another user C. If such wide-spreading digital data is 
billed for on the usage basis, copyright holders can 45 
enjoy benefits brought thereby. Basically, this copyright 
protection system is developed by taking such case into 
consideration. 

[0027] FIG. 4 is a diagram specifically showing the 
copyright protection system used for such case as 50 
above. In FIG. 4, with the first digital data recording and 
reproducing apparatus 1011, the user A presumably 
downloads music data from the content server 102 
(Step 1), and makes an online payment to the billing 
server 103 (Step 2). The user A then transmits the 55 
music data to the user B operating the second digital 
data recording and reproducing apparatus 1012 (Step 
3). The user B makes an online payment to the billing 



server 103 with respect to the music data (Step 4). 
Thereafter, the user B transmits the music data to the 
user C operating the third digital data recording and 
reproducing apparatus 1013 (Step 5). The user C 
makes an online payment to the billing server 103 with 
respect to the music data (Step 6). Herein, the users 
surely have an option not to pay for the music data, and 
may merely pass the music data to others. 
[0028] As such, the present copyright protection 
system can bill the users for the music data in the distri- 
bution process, benefiting the copyright holders to a 
greater extent. Moreover, the system may offer bonus 
such as coupon to encourage the users to distribute the 
music data thereamong. Details are left for later 
description. 

[0029] Next, the digital data recording and repro- 
ducing apparatus operated by the user as such is now 
described. FIG. 5 is a block diagram showing the struc- 
ture of the first digital data recording and reproducing 
apparatus 1011. The digital data recording and repro- 
ducing apparatus in FIG. 5 includes a super distribution 
data receiving unit 401 , a super distribution data storing 
region 402, an RMI acquiring unit 403, an RMI storing 
region 404, a content key extracting unit 405, a data 
reading unit 406, a data compressing unit 407, a data 
encrypting unit 408, an RMI adding unit 409, a data 
accessing unit 410, a distributor ID adding unit 411, a 
purchase processing unit 412, a content decrypting unit 
414, a reproduction controlling unit 41 5, a speaker 41 6, 
and a user ID storage region 418. 
[0030] Note herein that, the speaker 416 may be 
externally connected to the digital data recording and 
reproducing apparatus. Moreover, the RMI acquiring 
unit 403, the RMI storage region 404, the content key 
extracting unit 405, the data reading unit 406, the data 
compressing unit 407, the data encrypting unit 408, and 
the RMI adding unit 409 are provided, as will be 
described later, to convert unencrypted data, etc., to 
super distribution data. If there is no need for such con- 
version, these components may be omitted. Here, the 
second and third digital data recording and reproducing 
apparatuses 1012 and 1013 are structurally identical to 
the first digital data recording and reproducing appara- 
tus 1011, and thus are not described again. 
[0031] Such digital data recording and reproducing 
apparatus is generally implemented by a personal com- 
puter. FIG. 6 is a schematic diagram showing the struc- 
ture of the first digital data recording and reproducing 
apparatus 1011 implemented by a general computer 
device. 

[0032] The apparatus in FIG. 6 includes an informa- 
tion processing unit 2 operable to carry out data 
processing and controlling other components, a pro- 
gram storage unit 3 operable to store program data 
required for operating the information processing unit 2, 
an output unit 4 operable to display various information 
for the user and reproducing and outputting music data, 
etc., an input unit 5 operable to receive the user's 
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instructions and data from an external storage medium, 
a general data storage unit 6 operable to store data 
such as super distribution data, a secure data storage 
unit 7 operable to store data which is to be kept secret 
from the user in a region inaccessible by normal opera- 
tion, and a communications unit 8 operable to communi- 
cate with various servers via the Internet. These 
components are connected via a common system bus. 
[0033] The input unit 5 is exemplarily composed of 
a CD-ROM reader, DVD reader, keyboard, and mouse, 
and receives the user's instructions, and data, data from 
an external recording medium such as CD-ROM, and 
the like. The output unit 4 is exemplarily composed of a 
display, printer, and speaker, and displays various infor- 
mation generated by the information processing unit 2 
for the user, and plays back music. The information 
processing unit 2 exemplarily includes a CPU, and car- 
ries out various data processing to control other compo- 
nents while protecting a copyright of digital data. Such 
various data processing will be later described in detail. 
[0034] Herein, the information processing unit 2 
performs such various data processing with a program. 
The program is stored in the program storage unit 3, 
and is transmitted to the information processing unit 2 
as required. The program storage unit 3 may be so con- 
figured as to store program information in a recording 
medium such as fixed storage including hard disk drive 
or semiconductor memory, or in an exchangeable 
recording medium such as optical disk (e.g., CD, DVD) 
and semiconductor memory card. If the recording 
medium in use is of an exchangeable type, it may be 
exchanged with another having a new program stored 
as appropriate. 

[0035] The general data storage unit 6 is composed 
of a storage which is readable and writable such as hard 
disk drive and semiconductor memory, and stores data 
which is not necessarily kept secret from the user such 
as the super distribution data. The secure data storage 
unit 7 may be a storage such as hard disk or dedicated 
hardware, or a storage having an encrypted storage 
region set therein, and stores data to be kept secret 
from the user in a region inaccessible by normal opera- 
tion. The communications unit 8 is exemplarily com- 
posed of a modem and router, and communicates with 
the content server 102, billing server 103, or other dig- 
ital data recording and reproducing apparatuses via the 
Internet. 

[0036] Note herein that, the digital data recording 
and reproducing apparatus is not limited to a personal 
computer, but may be implemented by the so-called 
STB (Set Top Box) which records broadcasting pro- 
grams. 

[0037] Next, the operation of the first digital data 
recording and reproducing apparatus 1011 shown in 
FIG. 5 is described. This apparatus operates differently 
between the super distribution data and the unen- 
crypted data. Described next below is a first case where 
the user A receives the super distribution data, i.e., the 



first super distribution data in FIG. 2 or the second super 
distribution data in FIG. 3. 

[0038] In FIG. 5, the first or second super distribu- 
tion data is provided to the super distribution data 

5 receiving unit 401 from the content server 102, the sec- 
ond or third digital recording and reproducing apparatus 
1012 or 1013 operated by other user, or the external 
recording medium 417 such as CD. The data is then 
stored in the super distribution data storage region 402. 

w The storage location of the data is written to super dis- 
tribution data management information, which will be 
described later in detail, stored in the secured region. 
Although the secured region may be separately pro- 
vided from other storage regions, it is provided in the 

15 super distribution data storage region 402 in this appa- 
ratus. 

[0039] Described next is a second case where the 
user A receives the unencrypted music data from the 
external recording medium 417 such as CD. The unen- 

20 crypted music data may come from the content server 
1 02 or others. If that is the case, however, copyright pro- 
tection thereof is hardly protected, and thus such data is 
not taken into consideration here. Further, if the digital 
data recording and reproducing apparatus is configured 

25 without the RMI acquiring unit, the RMI storage region 
404, the content key extracting unit 405, the data read- 
ing unit 406, the data compressing unit 407, the data 
encrypting unit 408, and the RMI adding unit 409, the 
following operation is not carried out. 

30 [0040] In FIG. 5, the data reading unit 406 reads, 
from the external recording medium 417, unencrypted 
music data corresponding to the content 205 including 
the audio data 204. The RMI acquiring unit 403 
acquires right management information from the con- 

35 tent server 102 or the external recording medium 417. 
The acquired right management information is stored in 
the RMI storage region 404. 

[0041] FIG. 7 is a flowchart showing the detailed 
operation of the first digital data recording and repro- 

40 ducing apparatus 1011 for acquiring the right manage- 
ment information. In step S901, the RMI acquiring unit 
403 acquires content identifying information from the 
external recording medium 417 such as CD. The con- 
tent identifying information is an identification code such 

45 as ISRC or title information provided to identify the con- 
tents. 

[0042] In step S902, the RMI acquiring unit 403 
determines whether or not the external recording 
medium 417 has right management information corre- 

so sponding to the content specified by the acquired con- 
tent identifying information. If yes, the procedure goes 
to step S903, and otherwise, goes to step S904. 
[0043] In step S903, the RMI acquiring unit 403 
acquires the right management information from the 

55 external recording medium 417. The procedure then 
goes to step S905. Note herein that, the right manage- 
ment information recorded on the external recording 
medium 417 is encrypted under a predetermined 
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encryption system. Herein, the right management infor- 
mation may be recorded on the external recording 
medium such as CD or in a secured region of other type 
of recording medium such as SD (Secure Digital) card. 
[0044] In step S904, the RMI acquiring unit 403 
communicates with the content server 102 with security, 
and acquires right management information. Then, the 
procedure goes to step S905. 

[0045] In step S905, the acquired right manage- 
ment information is stored in the RMI storage region 
404, specifically, in a predetermined secured region 
provided in the digital data recording and reproducing 
apparatus 1011. Alternatively, the right management 
information is encrypted under a predetermined encryp- 
tion system, and a decryption key therefor is only stored 
in the secured region. 

[0046] In step S906, the RMI acquiring unit 403 
adds information relevant to the newly acquired right 
management information to a right management infor- 
mation managing table, which is for managing the right 
management information in the RMI storage region 404. 
[0047] FIG. 8 is a diagram showing an exemplary 
structure of the right management information manag- 
ing table. In FIG. 8, the right management information 
managing table includes an index number 1 501 , content 
identifying information 1502, and right management 
information storage location information 1503. The 
index number 1501 is assigned, in ascending order, to 
every right management information in the RMI storage 
region 404. In the example in FIG. 8, the RMI storage 
region 404 has seven different right management infor- 
mation. 

[0048] The content identifying information 1502 
includes the above-described content identifying infor- 
mation uniquely for each right management information. 
The right management information storage location 
information 1503 indicates the location where the right 
management information is stored. In the example in 
FIG. 8, the seven different right management informa- 
tion is each stored in a file in a Header directory in C- 
drive. 

[0049] The content read from the data reading unit 
406 is compressed by the data compressing unit 407 in 
a predetermined manner. Although the content is not 
necessarily compressed, the smaller data size is prefer- 
able for transmission/reception through the Internet. In 
terms of region size for storage, it is also preferable. 
[0050] The compressed content is encrypted by the 
data encrypting unit 408. A key used to encrypt the con- 
tent is the one extracted by the content key extracting 
unit 405 from the right management information stored 
in the RMI storage region 404. 

[0051] The RMI adding unit 409 adds the right man- 
agement information to the data encrypted by the data 
encrypting unit 408 so as to generate the first super dis- 
tribution data. Such generated first super distribution 
data is stored in the super distribution data storage 
region 402, and the storage location thereof is written to 



the super distribution data management information 
stored in the secured region. 

[0052] FIG. 9 is a diagram showing an exemplary 
structure of super distribution data management infor- 

5 mation 1605. The super distribution data management 
information 1605 in FIG. 9 includes an index number 
1601, data storage location information 1602, and a 
state of purchase 1603. The index number 1601 is 
assigned, in ascending order, to every super distribution 

10 data stored in the super distribution data storage region 
402. The data storage location information 1602 indi- 
cates the location where the super distribution data is 
stored. In the example in FIG. 9, the super distribution 
data is stored in seven different folders. The state of pur- 

15 chase 1603 indicates whether the super distribution 
data has been already purchased or not. 
[0053] If the super distribution data reached the 
super distribution data storage region 402 is the one 
came from the super distribution data receiving unit 

20 401, the state of purchase 1603 corresponding to the 
data is "not-yet-purchased". After a later-described bill- 
ing processing completed, the state of purchase 1603 is 
changed to "purchased". Herein, the state of purchase 
1603 may be indicated by a predetermined figure or a 

25 flag corresponding to a predetermined bit. 

[0054] If the super distribution data reached the 
super distribution data storage region 402 is the one 
obtained by encrypting data read by the data reading 
unit 406 from the external recording medium 417, for 

30 example, and by converting the data into the super dis- 
tribution data by the RMI adding unit 409, the state of 
purchase 1603 corresponding to the data is "pur- 
chased". This is because the user has already pur- 
chased the external recording medium 417. 

35 [0055] Described next is the operation of the digital 
data recording and reproducing apparatus 1011 in FIG. 
5 for reproducing such stored super distribution data 
therein and distributing the data to other users. 
[0056] Referring to FIG. 5, in response to the user's 

40 instruction for reproducing a certain content, an extrac- 
tion instructing unit (not shown) instructs the data 
accessing unit 410 to read the applicable super distribu- 
tion data from the super distribution data storage region 
402. The data accessing unit 410 then follows the 

45 instruction. 

[0057] In the case that the billing processing has 
been already completed or previewing is available, the 
content decrypting unit 414 takes out the content 205 
shown in FIG. 2 from the super distribution data 

50 accessed and extracted by the data accessing unit 410. 
The reproduction controlling unit 415 controls reproduc- 
tion of the extracted content, and then instructs the 
speaker 416 to output audio data. 
[0058] Such content decrypting unit 414 and the 

55 reproduction control unit 415 are described in detail for 
their operations by referring to FIG. 10. FIG. 10 is a flow- 
chart showing the processing carried out to reproduce 
the super distribution data stored in the super distribu- 
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tion data storage region 402. 

[0059] In step S1301, the content decrypting unit 
414 takes out, from the super distribution data extracted 
by the data accessing unit 410, the content key 202 and 
the billing control information 201 included in such right 5 
management information 203 as shown in FIG. 2. As 
already described, a specific software uses the right 
management information key to decrypt such informa- 
tion. 

[0060] In step S1303, the content decrypting unit 10 
414 refers to the super distribution data management 
information 1605 and checks whether the state of pur- 
chase 1603 for the super distribution data to be repro- 
duced indicates "purchased". If yes, the procedure 
jumps to step S1305, and otherwise, goes to step 15 
S1304. 

[0061] In step S1304, the content decrypting unit 
414 refers to the billing control information 201 included 
in the decrypted right management information 203, 
and checks whether previewing is available. If available, 20 
the procedure goes to step S1305, and otherwise, this 
is the end of the processing and the decrypted content 
is discarded. If the previewing is available for several 
number of times, the number is referred to in the billing 
control information 201. The previewing is available for 25 
the number of times, which is decremented by every lis- 
tening. 

[0062] In step S1305, the content decrypting unit 
414 uses the extracted content key 202 to decrypt the 
encrypted content included in the super distribution 30 
data accessed and extracted by the data accessing unit 
410. Further, the reproduction controlling unit 415 con- 
trols reproduction of the extracted content, and then 
instructs the speaker 416 to output music, for example. 
Herein, in order to record the number of listenings for 35 
the content, the number of listenings in the right man- 
agement information 203 is incremented, and then the 
information is encrypted again and converted back into 
the super distribution data for storage in the super distri- 
bution data storage region 402. Similarly, when the 40 
number of permissive previewing is already set, the 
number in the right management information 203 is dec- 
remented, and then the information is encrypted again 
and converted back into the super distribution data for 
storage. Further, if the billing is made for every listening, 45 
the corresponding state of purchase 1603 is changed to 
"not-yet-purchased" immediately after the playback. 
[0063] Described below is a case where the content 
is distributed to other users. Referring to FIG. 5, in 
response to the user's instruction for distributing some so 
super distribution data, similarly to the case for repro- 
duction, the extraction instructing unit instructs the data 
accessing unit 410 to access and extract the applicable 
super distribution data. The distributor ID adding unit 
411 searches the user ID storage region 418 for the 55 
specific user ID so as to generate the second super dis- 
tribution data 505 therewith. The generated second 
super distribution data 505 is exemplarily transmitted to 



the second digital data recording and reproducing appa- 
ratus 1012. Herein, the data can surely be transmitted 
to other digital data recording and reproducing appara- 
tuses, or recorded in an easy-to-carry recording 
medium such as SD card and handed to other users. 
[0064] Next below, the distributor ID adding unit 41 1 
is described for its structure and operation in detail. FIG. 
11 is a block diagram showing the detailed structure of 
the distributor ID adding unit 411. The distributor ID 
adding unit 411 in FIG. 11 includes a user ID acquiring 
unit 501 , a user ID encrypting unit 502, a user ID adding 
unit 503, and a management information acquiring unit 
504. 

[0065] The user ID acquiring unit 501 acquires a 
specific user ID from the secured region, i.e., the user 
ID storage region 418. The specific user ID is an identi- 
fication code uniquely provided to each user or digital 
data recording and reproducing apparatus. Note herein 
that, the specific user ID may be previously stored in the 
user ID storage region 418, or may be provided by an ID 
providing server or the billing server 103 through a pre- 
determined procedure. 

[0066] The management information acquiring unit 
504 reads, via the data accessing unit 410, the super 
distribution data management information 1605 stored 
in the secured region. Thereafter, the state of purchase 
1603 in the read super distribution data management 
information 1605 is inputted to the user ID encrypting 
unit 502. 

[0067] The user ID encrypting unit 502 then writes 
the state of purchase 1603 inputted from the manage- 
ment information acquiring unit 504 to the user ID 
acquired by the user ID acquiring unit 501 . Typically, the 
user ID is composed of ID and the state of purchase. 
Thereafter, the user ID encrypting unit 502 encrypts the 
user ID under a predetermined encryption system. 
[0068] The user ID adding unit 503 adds the user ID 
encrypted by the user ID encrypting unit 502 to the 
super distribution data accessed and extracted by the 
data accessing unit 41 0, and thus generates the second 
super distribution data 505. 

[0069] In the case that the super distribution data 
accessed and extracted by the data accessing unit 410 
is the first super distribution data having no user ID 301 
provided, simply the distributor ID may be provided 
thereto. On the other hand, for the second super distri- 
bution data having the user ID already provided, the dis- 
tributor ID may be added in various manners. 
[0070] For example, the already-provided user ID 
may be deleted before the distributor ID is added, or 
accompanied by the distributor IDs in time order. For the 
latter case that the distributor IDs are plural, the number 
thereof may be limited to the last several. Herein, the 
user IDs are assumed to be the last two, specifically, the 
distributor ID of this apparatus is followed by another 
distributor ID belonging to the apparatus from which the 
data has been distributed. 

[0071] In such manner, no matter which type of 
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super distribution data is accessed and extracted by the 
data accessing unit 410, i.e., the first or second super 
distribution data, the user ID adding unit 503 adds the 
encrypted user ID at the head thereof so that the user 
IDs are the last two at most. The second super distribu- 
tion data 505 is thus generated. 

[0072] Described next below is the purchase 
processing in the digital data recording and reproducing 
apparatus 1011. As described in the foregoing, the 
super distribution data stored in the super distribution 
data storage region 402 includes the data not-yet-pur- 
chased. Therefore, in response to the user's instruction 
for purchase, a purchase instructing unit (not shown) 
instructs the purchase processing unit 412 to read the 
super distribution data storage region 402 for the appli- 
cable super distribution data. The purchase processing 
unit 412 then follows the instruction, and then goes 
through the billing processing. 

[0073] FIG. 12 is a block diagram showing the 
detailed structure of the purchase processing unit 412. 
The purchase processing unit 412 in FIG. 12 includes 
an RMI extracting unit 601, a billing control information 
extracting unit 602, a distributor ID extracting unit 603, a 
billing processing information generating unit 604, a bill- 
ing processing information transmitting unit 605, a 
transmitter ID transmitting unit 606, a normal termina- 
tion receiving unit 607, and a super distribution data 
management information rewriting unit 608. 
[0074] The RMI extracting unit 601 extracts right 
management information from the read super distribu- 
tion data 610. The billing control information extracting 
unit 602 then extracts billing control information from the 
right management information extracted by the RMI 
extracting unit 601. If the read super distribution data 
has any user ID added, the distributor ID extracting unit 
603 extracts the user ID, and then instructs the billing 
processing information generating unit 604 to add the 
extracted user ID. To the extracted billing control infor- 
mation, the billing processing information generating 
unit 604 adds the user ID extracted by the distributor ID 
extracting unit 603 so as to generate the billing process- 
ing information 611. As such, the billing processing 
information transmitting unit 605 transmits such gener- 
ated billing processing information 611 to the billing 
server 103. 

[0075] FIG. 13 is a diagram showing an exemplary 
structure of the billing processing information 61 1 . The 
billing processing information 611 in FIG. 13 includes 
billing control information 702 extracted by the billing 
control information extracting unit 602, and a user ID 
701 extracted by the distributor ID extracting unit 603. 
Herein, when the read super distribution data has no 
user ID added, the billing processing information 611 
includes only the billing control information 702. The 
user ID 701 extracted by the distributor ID extracting unit 
603 may include not only the distributor ID belonging to 
the user who has distributed the data to the apparatus 
but another involved in data distribution precedent 



thereto. 

[0076] Simultaneously or immediately after the bill- 
ing processing information transmitting unit 605 trans- 
mits such billing processing information 611 as in FIG. 

5 13, the transmitter ID transmitting unit 606 transmits, to 
the billing server 103, a transmitter ID 612, which is the 
specific user ID acquired from the secured region for the 
purpose of identifying the transmitter. Typically, such 
information is sequentially transmitted as a set of data. 

10 [0077] The normal termination receiving unit 607 
receives, from the billing server 103, a billing processing 
normally terminated notice 613, which tells that the bill- 
ing processing has been normally completed. Once the 
billing processing normally terminated notice 613 is 

15 received, the super distribution data management infor- 
mation rewriting unit 608 changes the state of purchase 
1603, from "not-yet- purchased" to "purchased", in the 
super distribution data management information 1605 
stored in the super distribution data storage region 402. 

20 [0078] Described next is the operation for purchas- 
ing such super distribution data by referring to a flow- 
chart shown in FIG. 14. In step S1201 in FIG. 14, the 
RMI extracting unit 601 extracts right management 
information from the read super distribution data 610. 

25 [0079] In step S1202, the billing control information 
extracting unit 602 uses the above-described right man- 
agement information key to decrypt the extracted right 
management information. Such decryption is carried 
out by a dedicated software as described in the forego- 

30 ing. In step S1203, the billing control information 
extracting unit 602 extracts billing control information 
from the decrypted right management information. The 
extracted billing control information is the one included 
in the billing processing information 611. 

35 [0080] In step S1204, the distributor ID extracting 
unit 603 determines whether the read super distribution 
data is the second super distribution data. If yes, the 
procedure goes to step S1205, and otherwise, jumps to 
stepS 1207. 

40 [0081] In step S1205, the distributor ID extracting 
unit 603 extracts the user ID from the second super dis- 
tribution data. In step S1206, the distributor ID extract- 
ing unit 603 then adds the extracted user ID to the billing 
control information so as to generate such billing 

45 processing information 611 as shown in FIG. 13. 

[0082] In step S1207, the billing processing infor- 
mation transmitting unit 605 transmits the billing 
processing information 611 to the billing server 103. 
Simultaneously therewith, or sequentially, the transmit- 

50 ter ID transmitting unit 606 acquires the transmitter ID 
from the secured region, and then transmits the trans- 
mitter ID to the billing server 103. 
[0083] In step S1 208, after a lapse of time taken for 
the billing server 103 to go through the processing, the 

55 normal termination receiving unit 607 determines . 
whether the billing processing normally terminated 
notice 613 has been transmitted from the billing server 
103. If yes, the procedure goes to step S1209, and oth- 
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erwise, returns to step S1207. Herein, if the billing 
processing normally terminated notice 613 is not trans- 
mitted no matter how many times the processing in step 
S1207 is repeated, the billing server 103 may have 
gone down. Accordingly, a predetermined processing 5 
(not shown) is carried out to handle errors. 
[0084] In step S1209, the super distribution data 
management information rewriting unit 608 reads the 
super distribution data management information 1605 
from the super distribution data storage region 402, w 
changes the state of purchase 1603 therein from "not- 
yet-purchased" to "purchased", and then records the 
information again in the super distribution data storage 
region 402. 

[0085] In the above description, the billing process- 15 
ing information is presumed to be transmitted to the bill- 
ing server online. However, the billing processing 
information may be once stored in the digital data 
recording and reproducing apparatus, and then trans- 
mitted to the billing server whenever is appropriate. 20 
[0086] Next, the billing server 103 carrying out the 
billing processing is described for its structure and oper- 
ation. FIG. 15 is a diagram showing the structure of a 
billing processing unit 801 provided in the billing server 
103. The billing processing unit 801 in FIG. 15 includes 25 
a billing processing information receiving unit 802, a 
transmitter authorizing unit 803, a billing processing unit 
804, a normal termination notifying unit 805, a distribu- 
tor ID extracting unit 806, a distributor ID decrypting unit 
807, and a bonus processing unit 808. 30 
[0087] The billing processing information receiving 
unit 802 receives the billing processing information 611 
transmitted from the purchase processing unit 412. The 
billing processing information then goes to the billing 
processing unit 804 and the distributor ID extracting unit 35 
806. The transmitter authorizing unit 803 receives the 
user ID 612 came from the purchase processing unit 
412 in the first digital data recording and reproducing 
apparatus 1011, and then specifies the transmitter. 
[0088] Based on the billing control information 40 
included in the received billing processing information, 
the billing processing unit 804 carries out the billing 
processing with respect to the user specified by the 
transmitter authorizing unit 803. The normal termination 
noticing unit 805 then transmits the billing processing 45 
normally terminated notice 613 to the purchase 
processing unit 41 2 in the first digital data recording and 
reproducing apparatus 1011. 

[0089] If the billing processing information 611 is 
provided with the user ID specifying the distributor, the so 
distributor ID extracting unit 806 extracts the distributor 
ID. As described in the foregoing, the extracted distribu- 
tor ID may be both the current and previous distributor 
IDs. The distributor ID decrypting unit 807 decrypts the 
distributor ID extracted by the distributor ID extracting 55 
unit 806. The bonus processing unit 808 goes through 
the bonus processing with respect to the user specified 
by the decrypted user ID. Details are described later. 



[0090] Described next is the detailed operation of 
the billing processing unit 801 by referring to FIG. 16. 
FIG. 16 is a flowchart showing the processing for each 
component in the billing processing unit 801. 
[0091] In step S1401, the billing processing infor- 
mation receiving unit 802 receives the billing processing 
information 611 from the purchase processing unit 412, 
while the transmitter authorizing unit 803 receives the 
transmitter ID from the purchase processing unit 412. 
[0092] In step S1402, the billing processing unit 804 
carries out the billing processing with respect to the 
user specified by the transmitter ID received by the 
transmitter authorizing unit 803. This processing is done 
based on the billing control information included in the 
billing processing information which has been received 
by the billing processing information receiving unit 802. 
Herein, as already described, the billing control informa- 
tion includes a bill, for example, necessary for billing. 
[0093] In step S1403, the distributor ID extracting 
unit 806 determines whether the billing processing infor- 
mation received by the billing processing information 
receiving unit 802 is provided with any user ID. If yes, 
the procedure goes to step S1404, and otherwise, 
jumps to step S1406. 

[0094] In Step S1404, the distributor ID decrypting 
unit 807 decrypts the user ID in a predetermined man- 
ner. Herein, the user ID may be both the current and 
previous distributor IDs. 

[0095] In step S1405, the bonus processing unit 
808 carries out the bonus processing with respect to the 
user specified by the decrypted user ID. The user, 
thereby, is offered with discount or coupon, which is 
effective for the next bill. Herein, as described in the 
foregoing, the user entitled to such bonus may be both 
the current and previous distributors. If this is the case, 
the bonus processing unit 808 increases the discount 
rate or the face value of coupon for the current distribu- 
tor more than the previous distributor. This is because, 
the current distributor is the one who directly involved 
with the data distribution, but the previous distributor 
indirectly. 

[0096] The decrypted user ID is provided with the 
above-described billing information. Accordingly for the 
user who has already purchased the music data, the 
bonus processing unit 808 increases the discount rate 
or the face value of coupon more than the user who has 
not yet. 

[0097] As is known from the above, in the present 
digital data copyright protection system, user's bill pay- 
ment and his/her contribution to the distribution deter- 
mine the discount rate or the face value of coupon. In 
this manner, the user may be willing to purchase data or 
involve in the data distribution to increase the value of 
his/her bonus. With such user's involvement, the 
present digital data copyright protection system can 
benefit copyright holders to a greater extent while pro- 
tecting their copyrights. 

[0098] In the above, the bonus for the user is exem- 
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plarily discount or coupon, but is not restrictive thereto. 
The bonus may be varied to a point exchangeable with 
merchandise, merchandise, or special service, anything 
is possible as long as the bonus attracts the users well 
enough. 

(Second Embodiment) 

[0099] A digital data copyright protection system 
according to a second embodiment of the present 
invention is almost the same as the one described in the 
first embodiment. Specifically, the content server 102 
and the billing server 103 herein are identical to those in 
the first embodiment. In addition, the digital data record- 
ing and reproducing apparatus herein is also almost the 
same in structure. Therefore, in the second embodi- 
ment, only any difference from the first embodiment is 
described. Any identical component shares the same 
reference numeral, and is not described again. 
[0100] FIG. 17 is a block diagram showing the 
structure of a digital data recording and reproducing 
apparatus 1701 of the second embodiment. In FIG. 17, 
the digital data recording and reproducing apparatus 
1701 includes the super distribution data receiving unit 
401, the super distribution data storage region 402, the 
RMI acquiring unit 403, the RMI storage region 404, the 
content key extracting unit 405, the data reading unit 
406, data compressing unit 407, the data encrypting 
unit 408, the RMI adding unit 409, the data accessing 
unit 410, the distributor ID adding unit 41 1, the purchase 
processing unit 412, the content decrypting unit 414, 
the reproduction control unit 415, the speaker 416, the 
user ID storage region 418, a data adding unit 1702, an 
additional information storage region 1703, and a dis- 
play 1704. 

[0101] As is known from the above, the difference 
from the first digital data recording and reproducing 
apparatus 1011 of the first embodiment is in that the 
data adding unit 1702, the additional information stor- 
age region 1703, and the display 1704 are additionally 
provided. Described next below is the operation of the 
data adding unit 1702. 

[0102] The data adding unit 1702 reads, from the 
additional information storage region 1703, image data 
previously provided by the user and/or additional infor- 
mation including reproduction control information as to 
the image data and audio data. Such image data and/or 
information is added to the audio data which has been 
compressed by the data compressing unit 407. Typi- 
cally, the additional information is provided at the tail of 
the audio data, which is composed of one or more 
pieces. Specifically, the additional information is pro- 
vided at the tail of the audio data 204 in the content 205 
in FIG. 2. Note herein that, the additional information 
may be previously provided to the audio data to be com- 
pressed together with the audio data. 
[0103] Herein, the image data provided by the user 
is displayed at a predetermined timing when the content 



is reproduced. The reproduction control information is 
for to control reproduction of the content. For example, 
the reproduction control information controls an order 
and timing to reproduce the audio data, if plural, or con- 
5 trols a timing to display the image data provided by the 
user. 

[0104] The data encrypting unit 408 subjects the 
audio data having the image data added by the data 
adding unit 1702 to encryption. Surely, only the audio 

10 data may be encrypted. Now and onwards, the digital 
data recording and reproducing apparatus 1701 oper- 
ates in a similar manner to the first digital data recording 
and reproducing apparatus 1011 of the first embodi- 
ment, and is not described again. 

15 [0105] Note herein that, in the apparatus shown in 
FIG. 17, the speaker 416 is used to reproduce the con- 
tent, and the display 1704 may be also used to display 
the image. As already described by referring to FIG. 6, 
when this apparatus is implemented by a common per- 

20 sonal computer, the display may be a CRT or others to 
display various information. Therefore, when the con- 
tent includes the image data, the image is to be dis- 
played on the display 1704 popular for the personal 
computer. 

25 [0106] As described in the foregoing, according to 
the present digital data copyright protection system, 
there is no more need to encrypt CDs to charge appro- 
priate royalties therefor and protect the copyright 
thereof. Further, with the reproduction control informa- 

30 tion on image and audio provided by the user, the music 
content for distribution as super distribution data can be 
more entertaining. 

(Third Embodiment) 

35 

[0107] As the third embodiment, as a specific 
example of super distribution data as mentioned in the 
first and second embodiments, a content distribution 
format called SDAF (Secure Digital Audio Format) is 

40 described below. Referring to FIGS. 18 to 39, details on 
the SDAF is first described, and then referring to FIGS. 
40 to 45, how to use the SDAF is described. 
[0108] The content distribution format (SDAF) 
according to the present embodiment is used for 

45 describing multimedia contents that include audio, 
images, video, text, and file data. The multimedia con- 
tents described with SDAF are herein called an SDAF 
title. Presentation data each comprising the SDAF title 
is herein called a content element (hereinafter abbrevi- 

so ated as CEL). Each CEL is assigned a CEL identifier 
that is unique in the SDAF title (hereinafter abbreviated 
as CELJD). 

[0109] The SDAF title is distributed as being split 
into units called SDAF packages. Each SDAF package 
55 is assigned a package identifier that is unique in the 
entire distribution system. FIG. 18 is a diagram showing 
an example of the SDAF package. As shown in FIG. 18, 
an SDAF title 2000 is composed of a plurality of SDAF 
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packages. Each package 2001 is composed of a header 
2011, navigation data 2012, a plurality of CELs 2013, 
and an offer 2014. 

[0110] The header 2011 includes information such 
as location, size, and attribute of each data in the pack- 5 
age. Such information defines the package structure. 
The navigation data 2012 is playback control informa- 
tion specifying the operation of the player in playing 
back the SDAF title. From the navigation data 2012, a 
CEL included in the package to which the navigation 10 
data belong or in other packages is referred to. The CEL 
2013 is obtained by encrypting each presentation data 
composing the SDAF title, and more specifically, by 
encrypting audio, images, video, text, or file data. A pair 
of a decryption key for decrypting the CEL 2013 and 15 
CELJD is called a key pair. The offer 2014 includes a 
plurality of key pairs, and purchase rules describing the 
purchase price and available period for each key pair. 
[0111] FIGS. 19a to 19c are diagrams showing 
three types of SDAF packages. A full package 2001 20 
shown in FIG. 19c includes, similarly to FIG. 18, a 
header 2011, navigation data 2012, a plurality of CELs 
2013, and an offer 2014. An offer package 2002 shown 
in FIG. 19a includes the header 2011, the navigation 
data 2012, and the offer 2014, but does not include any 25 
CEL 2013. A CEL package 2003 shown in FIG. 19b 
includes the header 2011 and the plurality of CELs 
2013. Since the navigation data 2012 is required for 
playing back the SDAF title, the full package 2001 and 
the offer package 2002 can be played back alone, but 30 
the CEL package 2003 cannot. 

[0112] The CEL package is used for splitting the 
SDAF title according to the distribution channel. For 
example, when distributed by using a CD-ROM, the 
SDAF title is recorded as a full package in the CD-ROM. 35 
On the other hand, when distributed through the Inter- 
net, the SDAF title is split into one full package and a 
plurality of CEL packages for distribution. For example, 
the SDAF title is split into one full package including an 
audio CEL and a plurality of CEL packages including a 40 
video CEL that is referred to from the full package for 
distribution. 

[0113] Further, as shown in FIG. 20, the SDAF title 
may be split into a plurality of SDAF packages by tracks. 
In package division as shown in FIG. 20, an SDAF title 45 
2020 including audio data for five tracks is split into 
three packages 2021 to 2023. The first to third pack- 
ages 2021 to 2023 have package names Singlel, 
Single2, and album, respectively. The first and second 
packages 2021 and 2022 both include an audio CEL for so 
one track and navigation data for controlling playback of 
the CEL. The third package 2023 includes an audio 
CEL for three tracks and navigation data for controlling 
playback of all audio CELs included in the first to third 
packages 2021 to 2023. As such, by dividing the SDAF 55 
title into a plurality of SDAF packages, it is possible to 
make each data size smaller and easily handle each 
data. 
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[0114] The header, offer, navigation data, and CEL, 
which compose the SDAF package, are described in 
this order below. 

[0115] The header 2011 is first described. Here, an 
SDAF package shown in FIG. 21 is taken as an exam- 
ple, and a header 2031 of an SDAF package 2030 is 
described. In the SDAF package 2030, it is herein 
assumed that the size of navigation data 2032 and the 
size of an offer 2034 are 400H each, in hexadecimal 
notation. This package includes three CELs 2033, and 
the types thereof are, from first, audio, image, and file. It 
is assumed here in that the sizes of these CELs are, 
from first, 400000H, 18000H, and 8000H in hexadeci- 
mal notation. 

[0116] FIG. 22 is a diagram showing the structure of 
the header 2031 . In the header 2031 , data as described 
below is sequentially stored, and the size of the header 
is BCH in hexadecimal notation. Note that the structure 
of the header 2031 can be described in the C++ lan- 
guage as shown in FIGS. 23 and 24. FIGS. 23 and 24 
are a diagram showing a sequential source code as 
being split into two, and before division, a source code 
2062 shown in FIG. 24 follows a source code 2061 
shown in FIG. 23. 

[0117] At the start of the header 2031, a magic 
number 2041 (4 bytes) indicating that the file is in the 
SDAF format is stored. The value of the magic number 
2041 is a character string "SDAF". Then, a version 
number 2042 (4 bytes) of the SDAF is stored. Then, a 
package ID 2043 (16 bytes) and a package size 2044 (4 
bytes) are stored. Then, navigation data location infor- 
mation 2045 (SDAF_LOCATION_NAV in FIG. 23), offer 
location information 2046 (SDAF_LOCATION_OFFER 
in FIG. 23), and the number of CELs in the package 
2047 are stored. Then, CEL information 2048 
(SDAF_LOCATION_CEL in FIG. 24) for each CEL is 
stored. Lastly, a CEL attribute table 2049 indicating an 
attribute of each CEL is stored. 

[0118] The navigation data location information 
2045 indicates the location and size of the navigation 
data 2032. The offer location information 2046 indicates 
the location and size of the offer 2034. These two pieces 
of information are both composed of an offset (4 bytes) 
from the start of the SDAF package and each size (4 
bytes) thereof. 

[0119] The CEL information 2048 is composed of a 
CELJD 2051 (16 bytes), a CEL type 2052 (2 bytes), a 
CEL encryption type 2053 (2 bytes), a CEL data loca- 
tion information 2054, and a CEL attribute table location 
information 2055. The CELJD 2051 is a content ele- 
ment identifier that is unique in the SDAF title. The CEL 
type 2052 takes any value of audio, image, video, text, 
and file. The CEL encryption type 2053 indicates an 
algorithm used for encrypting the CEL. The CEL data 
location information 2054 and CEL attribute table loca- 
tion information 2055 are both composed of an offset (4 
bytes) from the start of the SDAF package and each 
size (4 bytes) thereof. If the offset or size is 0, that 
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means no data exists. 

[0120] The CEL attribute table 2049 is a list of 
attributes specified for each CEL type. An audio CEL 
attribute table (SAD F_ATTR_ AUDIO in FIG. 24) 
includes at least CODEC, the number of quantized bits, 5 
sampling frequency, and the number of audio channels. 
An image CEL attribute table (SDAF_ATTR_GRAPHIC 
in FIG. 24) includes at least the height and width of the 
image and the encryption type. A video CEL attribute 
table includes at least the height and width of the video w 
and the encryption type. A text attribute table includes at 
least the encryption type of the text, such as Unicode or 
music shift JIS (Japanese Industrial Standards). A file 
CEL attribute table includes at least the type of MIME 
(Multipurpose Internet Message Extension). 15 
[0121] The CEL attribute table 2049 is defined not 
as a fixed-length table but with a variable-length tag 
structure as shown in FIGS. 25a to 25c. If the tag struc- 
ture is used, a tag length and tag ID are stored preced- 
ing the data, as shown in FIG. 25a. For example, the 20 
image CEL attribute table is composed of a characteris- 
tic tag 2063 and an encryption type tag 2064. The table 
elements are specified by using the tag structure, 
thereby a new table element can be added to the data 
format or the data format can be changed only by add- 25 
ing a tag. The CEL attribute table is specified by using 
the tag structure with a great potential for expansion. 
[0122] Next, the offer 2014 is described. As stated 
above, the offer includes a plurality of key pairs and pur- 
chase rules for each key pair. Each key pair is com- 30 
posed of a decryption key for decrypting the CEL and a 
CELJD. FIG. 26 is a diagram showing the correspond- 
ence between the key pair and the CEL. As shown in 
FIG. 26, a key pair 2072 is composed of a decryption 
key 2073 and a CELJD 2074, and each key pair 2072 35 
is related to each CEL 2071 . The offer includes not only 
the key pair of the CEL included in the SDAF package 
but also all key pairs of the CELs included in the SDAF 
packages of the same SDAF title. In other words, when 
one SDAF title is split into a plurality of SDAF packages, 40 
only one SDAF package includes an offer, and this offer 
includes all key pairs of the CELs included in the SDAF 
title. 

[0123] The purchase rules are described by using a 
language for describing use conditions of the key pair, 45 
called right management language. The use conditions 
of the key pair include the date of purchase, use period, 
and whether a specific CEL or SDAF title has been pur- 
chased or not. The purchase rules are specified by 
using these use conditions, and thereby the same CEL so 
can be sold at different prices depending on the condi- 
tions. 

[0124] Next, the navigation data 2012 is described. 
The navigation data is created by a content creator so 
that the user can use the CEL most effectively, defining 55 
the logic structure of the SDAF title. 
[0125] In SDAF, XML (extensible Markup Lan- 
guage), which is a tag description language in a text for- 



mat, is used for describing the navigation data. When 
the data structure is described in XML, a tag structure in 
a text format is used. Therefore, data described in XML 
is redundant compared with binary data. Nevertheless, 
XML is adopted because of its excellent expandability. 
[0126] To refer to the CEL from the navigation data, 
a CEL locator is used. The CEL locator is a concatena- 
tion of the package ID and CEL_ID taking '?' (question 
mark) as a delimiter. However, for the CEL included in 
the SDAF package that includes the navigation data, 
the package ID and the delimiter are omitted, and the 
CELJD becomes the CEL locator. The CEL locator can 
specify the CEL independently of the physical address 
of the CEL. 

[0127] FIG. 28 is a diagram showing how to refer to 
the CEL from the navigation data by using the CEL loca- 
tor. In FIG. 28, navigation data 2081 and presentation 
data 2082 are shown as an example. The presentation 
data 2082 includes an audio CEL 2083 encoded with 
MPEG2-AAC and an image CEL 2084 encoded with 
JPEG. The package ID and CELJD of the audio CEL 
2083 are both 1, while those of the image CEL 2084 are 
1 and 2, respectively. In this case, a CEL locator "1?1" 
included in the navigation data 2081 indicates the audio 
CEL 2083 with its package ID "1" and CELJD "1". A 
CEL locator "1 ?2" indicates the image CEL 2084 with its 
package ID "1" and CELJD "2". As known from this 
example, only a change in the package ID of the CEL 
locator after creation of the SDAF title can cause a 
change in the structure of the SDAF package. There- 
fore, it is possible to structure the SDAF title as a single 
package or split the SDAF title into a plurality of SDAF 
packages. 

[0128] FIGS. 29 and 30 are diagrams showing the 
structure of the navigation data based on the following 
representation manner. Each rectangle represents an 
element of the navigation data. An arrow drawn from an 
element A to an element B indicates that the element A 
includes the element B as a descendant element. Each 
mark provided at the start of each arrow indicates as fol- 
lows: * indicates that the element includes 0 or more 
descendant elements; + indicates that the element 
includes 1 or more descendant elements; and ? indi- 
cates that the element includes 0 or 1 descendant ele- 
ment. If the element A includes an item P without any 
arrow, that means the element A has the item P as an 
attribute. Underlined items represent CEL locators. 
PCDATA represents a character string composed of 
characters included in a predetermined character set. 
This representation specifies a hierarchical structure 
with a TITLE element as a root. 

[0129] A TITLE element 2101 describes shipping 
information of the SDAF title. This element has three 
attributes: UPC, VERSION, and LANGUAGE. The UPC 
attribute describes a UPC (Universal Product Code), 
which is the international standards of product codes. 
The VERSION attribute describes the version number 
of the SDAF navigation structure. The LANGUAGE 
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attribute describes the type of language according to 
ISO 639. Its default value is "en" indicating English. 
[0130] A METADATA element 2102 describes infor- 
mation such as genre of a PLAYLIST or TRACK ele- 
ment. The METADATA element has a TYPE attribute. 5 
The TYPE attribute describes the type of the META- 
DATA element. 

[0131] An ASSOC element 2103 describes refer- 
ence information to a CEL included in other SDAF titles. 
This element has a REF attribute. The REF attribute 10 
describes the CEL locator. 

[0132] A URL element 2104 describes the URL 
(Uniform Resource Locator). This element has two 
attributes: ID and TYPE. The ID attribute describes the 
identification number of this element. The TYPE 15 
attribute describes the type of the URL element. 
[0133] A PLAYLIST element 2105 describes a play- 
list, which is a basic unit for the SDAF title. The playlist 
corresponds to an album in the conventional package 
media, and is included in all SDAF titles. The PLAYLIST 20 
element may include a MENU element, which is a menu 
for the playlist. The PLAYLIST element has five 
attributes: NAME, ARTIST, PRODUCTID, THUBMNAI- 
LID, and ONSTART. The NAME attribute describes the 
name of the playlist. The PRODUCTID attribute 25 
describes information corresponding to a catalog code 
in a CD. The THUMBNAILID attribute describes the 
CEL locator of the image CEL that is typical in the play- 
list. The ONSTART attribute describes the operation for 
playing back the playlist. If the ONSTART attribute is 30 
"MENU", the player stops playing while displaying a 
playlist menu. If "TRACK", the player starts playing back 
the first TRACK element included in the PLAYLIST ele- 
ment. All PLAYLIST elements have at least one TRACK 
element 2106. 35 
[0134] The TRACK element 2106 describes the 
track including one audio CEL. The TRACK element 
may include a track menu, slideshow, text, file, and oth- 
ers. The TRACK element has seven attributes: ID, 
NAME, ARTIST, ISRC, AUDIOID, TSMID, and THUM- 40 
BAILID. The ID attribute describes the identification 
number that is unique in the SDAF title. The NAME 
attribute describes the name of the TRACK element. 
The ARTIST attribute describes the name of the artist. 
The ISRC attribute describes ISRC (International 45 
Standard Recording Code). The AUDIOID attribute 
describes the CEL locator of the audio CEL related to 
the TRACK element. The TSMID attribute describes the 
CEL locator of a time search map corresponding to the 
audio CEL. The time search map will be described later, so 
The THUMBNAILID attribute describes the CEL locator 
of the image CEL that is typical in the TRACK element. 
[0135] A MARKER element 2107 describes a 
marker for use in finding the start in the TRACK ele- 
ment. This element has two attributes: TIME and 55 
NAME. The TIME attribute describes the location of the 
marker in milliseconds. The NAME attribute describes 
the name of the marker. 
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[0136] A SYNCSLIDESHOW element 2108 
describes a slideshow for displaying slides or menus by 
following display timing information specified by a SYN- 
CMAP element 2109. The SYNCSLIDESHOW element 
2108 has three attributes: ID, NAME, and TYPE. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0137] The SYNCMAP element 2109 describes the 
display timing information for the slide or the menu 
specified in the SYNCSLIDESHOW element. The SYN- 
CMAP element 2109 has three attributes: MENUID, 
PLAYID, and TIME. The MENUID attribute describes 
the identification number of the slide or menu to be dis- 
played. The PLAYID attribute describes the index 
number for specifying a button to be set in a playback 
state on the menu. The TIME attribute describes the 
display timing in milliseconds. 

[0138] A SLIDESHOW element 21 10 describes the 
slideshow for displaying slides or menus at predeter- 
mined display intervals. This element has four 
attributes: ID, NAME, TYPE, and INTERVAL. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. The INTERVAL attribute describes the 
display interval of the slide or menu. 
[0139] A SYNCTEXT element 2111 describes text 
information to be displayed with predetermined timing. 
The text information is described by using a SYNC- 
TEXTBLOCK element 21 12. Alternatively, the text infor- 
mation may be specified by referring to part of the text 
CEL. The SYNCTEXT element has four attributes: ID, 
TEXTID, REFID, and TYPE. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The TEXTID attribute describes the CEL locator of the 
text CEL. The REFID attribute describes the identifica- 
tion number of a TEXTREF element in the text CEL 
specified by the TEXTID attribute. The TEXTREF ele- 
ment will be described later. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0140] The SYNCTEXTBLOCK element 2112 
describes the text information to be displayed with pre- 
determined timing. This element has a TIME attribute. 
The TIME attribute describes the display timing in milli- 
seconds. 

[0141] The TEXT element 21 1 3 describes text infor- 
mation. The text information is described in a text data 
format. Alternatively, the text information may be speci- 
fied by referring to part of the text CEL. The TEXT ele- 
ment has the same types of attributes as the 



14 



27 



EP 1 089 241 A2 



28 



SYNCTEXT element has. 

[0142] A VIDEO element 21 14 describes any exist- 
ing video CEL. This element has three attributes: ID, 
VIDEOID, and TYPE. The ID attribute describes the 
identification number that is unique in the SDAF title. 5 
The VIDEOID attribute describes the CEL locator of the 
video CEL. The TYPE attribute describes the informa- 
tion category in the track, such as credits, lyrics, liner 
notes, biography, image collection, or promotion. 
[0143] A FILE element 2115 describes any existing w 
file CEL. This element has three attributes: ID, FILEID, 
and TYPE. The ID attribute describes the identification 
number that is unique in the SDAF title. The FILEID 
attribute describes the CEL locator of the file CEL. The 
TYPE attribute describes the information category in 15 
the track, such as credits, lyrics, liner notes, biography, 
image collection, or promotion. 

[0144] A SLIDE element 2116 describes a slide. 
This element has three attributes: ID, NAME, and 
BACKGROUNDID. The ID attribute describes the iden- 20 
tification number that is unique in the SDAF title. The 
NAME attribute describes the name of the slide. The 
BACKGROUNDID attribute describes the CEL locator 
of the image CEL on a slide screen. 

[0145] A MENU element 2117 describes a menu. 25 
The menu has one or more onscreen buttons. The 
MENU element has four attributes: ID, NAME, BACK- 
GROUNDID, and SELECTID. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The NAME attribute describes the name of the menu. 30 
The BACKGROUNDID attribute describes the CEL 
locator of the image CEL displayed on a menu screen. 
The SELECTID attribute describes the index number for 
specifying a button to be set in a select state. 
[0146] A BUTTON element 2118 describes the 35 
onscreen buttons arranged on the menu screen. The 
BUTTON element includes, as descendant elements, 
one or more pairs of TEXTBUTTON and COMMAND 
elements or those of GRAPHICBUTTON and COM- 
MAND elements. The BUTTON element has seven 40 
attributes: INDEX, TAB, UP, DOWN, RIGHT, LEFT, and 
AUTOACTION. The INDEX attribute describes the 
index number that is unique in the MENU element. The 
TAB attribute describes the sequential number sequen- 
tially and circulatively provided for each of the buttons 45 
on the menu. The UP, DOWN, LEFT, and RIGHT 
attributes describe the index number of the selected 
destination button located upward, downward, leftward, 
and rightward, respectively, from the current button. The 
AUTOACTION attribute describes the flag indicating so 
whether the state is automatically changed from select 
to active. 

[0147] A TEXTBUTTON element 2119 describes 
the onscreen button represented by text. This element 
has eleven attributes: X, Y, WIDTH, HEIGHT, FORN- 55 
TSIZE, NORMALCOLOR, SELECTCOLOR, ACTION- 
COLOR, PLAYINGCOLOR, TEXTID, and REFID. The 
X, Y, WIDTH, and HEIGHT attributes each describe the 



display location of the button using a coordinate system 
taking the upper-left corner of the menu as the origin. 
The FONTSIZE element describes the font size in 
points. The NORMALCOLOR, SELECTCOLOR, 
ACTIONCOLOR, and PLAYINGCOLOR attributes 
describe a display color in RGB format when the button 
state is normal, select, active, and playback, respec- 
tively. The TEXTID attribute describes the CEL locator 
of an external text CEL. The REFID attribute describes 
the identification number of the TEXTREF element in 
the text CEL specified by the TEXTID. 
[0148] A GRAPHICBUTTON element 2120 
describes the onscreen button represented as graphics. 
This element has eight attributes: X, Y, WIDTH, 
HEIGHT, NORMALID, SELECTID, ACTIONID, and 
PLAYING ID. The X, Y, WIDTH, and HEIGHT attributes 
each describe the display location of the button using a 
coordinate system taking the upper-left corner of the 
menu as the origin. The NORMALID, SELECTID, 
ACTIONID, and PLAYINGID attributes each describes 
the CEL locator of the image CEL displayed when the 
button state is normal, select, active, and playback, 
respectively. 

[0149] A COMMAND element 2121 describes the 
navigation operation when the user presses one of the 
onscreen buttons. This element has two attributes: 
TYPE and TARGET. The TYPE attribute describes any 
one of SHOW, FUNCTION, GOTO, NEXT, and PREVI- 
OUS commands. The SHOW command is for displaying 
the element specified by the TARGET attribute. The 
FUNCTION command is for executing the element 
specified by the TARGET attribute. This command is 
used while a playlist menu is being displayed. The 
GOTO command is for moving from the element cur- 
rently displayed to a specified brother element. The 
NEXT command is for moving from the element cur- 
rently displayed to the next brother element. The PRE- 
VIOUS element is for moving from the element currently 
displayed to the previous brother element. The TARGET 
attribute describes the parameter of the command 
specified by the TYPE attribute. If the SHOW command 
is specified, the TARGET attribute describes the identi- 
fication number of the element to be displayed. If the 
FUNCTION command is specified, the TARGET 
attribute describes the identification number of the ele- 
ment to be executed. If the GOTO command is speci- 
fied, the TARGET attribute describes the identification 
number of the brother element of the element currently 
displayed. 

[0150] The TEXTREF element describes text cate- 
gory information for use in referring from the navigation 
data to part of the text data stored in the text CEL. The 
text data included in the TEXTREF element is referred 
to by specifying the identification number of the TEX- 
TREF element from the navigation data. The TEXTREF 
attribute has an ID attribute. The ID attribute describes 
the identification number that is unique in the SDAF 
tittle. 



15 



29 



EP 1 089 241 A2 



30 



[0151] Next, the CEL 2013 is described. The CEL 
has five types: audio, image, video, text, and file. In 
SDAF, the data format and parameter are specified for 
each type of the CEL. 

[0152] The data included in the audio CEL is audio 
data encoded in compliance with MPEG2-AAC 
(Advanced Audio Coding) [Low Complexity Profile]. 
Note that MPEG2-AAC is specified in ISO/IEC 13818-7: 
1997(E) Information technology - Generic coding of 
moving pictures and associated audio information - 
Part7 Advanced Audio Coding (AAC). The bit stream 
encoded with MPEG2-AAC is assumed to be in the 
ADTS (Audio Data Transport Stream) format. Further, 
parameters described in ISO/IEC 13818-7 are 
restricted as shown in FIG. 31. Of these parameters, 
parameters other than sampling_frequency_index and 
channel_configuration are restricted due to selection of 
LC-profile specified by ISO/IEC 13818-7. Further, the 
average bit rate is 64 or 128 kbps. 
[0153] Data included in the image CEL is image 
data encoded in compliance with JPEG, MPEG-I frame, 
or PNG (Portable Network Graphics). FIGS. 32, 33, and 
34 are tables showing specification of JPEG, MPEG-I 
frame, and PNG, respectively. The specifications for the 
encryption algorithms applied to the image CEL are 
restricted as shown in these figures. 
[0154] Data included in the video CEL is video data 
encoded in compliance with MPEG2. FIG. 35 is a table 
showing the specification of MPEG 2. The specification 
for the encryption algorithm applied to the video CEL is 
restricted as shown in FIG. 35. 

[0155] Data included in the text CEL is PLAIN text 
or XML text in SDAF. The encryption type is Unicode or 
music shift JIS. 

[01 56] As an example of the file CEL, a time search 
map CEL that includes a time search map as data is 
now described. The time search map is a table com- 
posed of address of an audio frame. FIG. 36 is a dia- 
gram showing the structure of the time search map. As 
shown in FIG. 36, a time search map 2090 is composed 
of a header 2091 and a plurality of entries 2092. FIGS. 
37, 38a, and 38b are a table and diagrams showing the 
header 2091 in detail. As shown in FIGS. 37, 38a, and 
38b, the header 2091 includes playback duration 
between entries described in milliseconds and the total 
number of entries. FIG. 39 is a table showing each entry 
in detail. As shown in FIG. 39, each entry includes the 
address of the audio frame at its entry point. The first 
entry indicates the starting location of the audio frame 
included in the audio CEL. 

[0157] Note that in the present embodiment, 
MPEG2-AAC is used for compressing music data 
included in the audio CEL. Alternatively, MP3 (MPEG1 
Audio Layer 3), Dolby-AC3, or DTS (Digital Theater 
System) may be used. 

[0158] Next, with reference to FIGS. 40 to 45, how 
to use the SDAF is described. As stated above, the 
SDAF is a format for describing multimedia contents, 



and mainly used for music data distribution. The SDAF 
can be applied to various types of recording media, typ- 
ically hard disks, optical disks such as DVD-RAM, and 
semiconductor memory such as memory cards. 

5 [0159] In addition to music data distribution, the 
SDAF can be used in combination with the existing 
music data. For example, to be mentioned below, the 
SDAF can be used in combination with music data com- 
plying with the DVD-Audio standards. Similarly the 

10 SDAF can be applied to other recording media such as 
DVD-Video, CD, Video-CD, and Photo CD. 
[0160] Music data complying with the DVD-Audio 
standards includes LPCM (Linear Pulse Code Modula- 
tion) audio contents and MPEG-I frame image contents. 

15 A player complying with the DVD-Audio standards dis- 
plays a menu screen for user's interactive operation. In 
the DVD-Audio standards, such menu screen is dis- 
played by superimposing a maximum of four-color sub 
video images onto a background image for display and 

20 providing a plurality of rectangular regions in the sub 
video images. Such rectangular regions are called but- 
tons, and each button is assigned a command. How- 
ever, some restrictions are applied to the number of 
display colors and the shape of the button and therefore 

25 the content creator cannot freely design the menu 
screen. 

[0161] This problem can be solved by previously 
recording data of the menu screen described in the 
SDAF in a conventional DVD-Audio disk, and displaying 

30 the menu screen using this data at playback. More spe- 
cifically the DVD-Audio disk records multimedia con- 
tents described in the SDAF and a CEL redirector for 
referring from the SDAF to the original DVD-Audio con- 
tents. Hereinafter, a DVD-Audio disk with such data 

35 recorded thereon is called an extended DVD-Audio disk, 
and a player for playing back the extended DVD-Audio 
disk is called SDAF-compliant DVD-Audio player. 
[0162] FIG. 40 is a diagram showing an example of 
the CEL redirectors that correspond to a single DVD- 

40 Audio disk. Each row indicates the CEL redirector for 
each content included in the original DVD-Audio disk. 
The CEL redirector includes a CELJD 2201 , file name 
2202, start address 2203, and end address 2204. The 
CELJD 2201 is a content identifier that is unique in the 

45 disk. The file name 2202 is a name of the file that 
includes each content. The start and end addresses 
2203 and 2204 are offset values indicating the start 
location and end location, respectively, of each content 
in the file. The CEL redirector is recorded in a file named 

so DVDA.MAP, for example, in an SDAF directory provided 
in the ROM area of the extended DVD-Audio disk. 
[0163] All various playback control functions such 
as audio playback order control, slideshow image play- 
back, and a menu function defined by the DVD-Audio 

55 standards can be described using the SDAF navigation 
data. For example, the menu function can be realized by 
superimposing JPEG button images having any number 
of colors and shape onto an MPEG-I frame background 
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image for display and relating each button region to a 
command. 

[0164] When playback control information included 
in the DVD-Audio disk is converted into SDAF naviga- 
tion data, information indicating a content is converted 5 
into the CELJD by using the CEL redirector. The menu 
screen is converted into JPEG button images. The 
obtained images are arranged at locations so as to be 
superimposed onto the background image. The naviga- 
tion data and button images as obtained in the above 10 
described manner are stored in a single SDAF package, 
and recorded in a file named SDAF.SDP, for example, in 
an SDAF directory provided in the ROM region of the 
extended DVD-Audio disk. The method of playing back 
the extended DVD-Audio disk will be described later. is 
[0165] Next, an SDAF player for playing back multi- 
media contents described with SDAF is described 
below. The SDAF player plays back distributed music 
data in the following manner. First, the player searches 
for the package IDs and navigation information to collect 20 
the CELJDs of the CELs required for playback. The 
player searches purchase database using sets of the 
collected package ID and CELJD to determine whether 
each CEL has been purchased or not. If any CEL not 
yet purchased is found, the player analyzes the 25 
encoded offer, and pays a predetermined price through 
the existing electronic distribution system. After pur- 
chasing, the key pair stored in the offer is stored in the 
purchase database. If determining that the SDAF pack- 
age required for playback is not found in the player, the 30 
player sends out the package ID to the data distribution 
apparatus. The data distribution apparatus distributes 
an SDAF package with the received package ID to the 
player. After purchasing all CELs required for playback, 
the player decrypts the CELs using the key pairs stored 35 
in the purchase database for playback. At this time, the 
player interprets the navigation data for playback con- 
trol. 

[0166] The SDAF title is distributed to the player as 
being split into one or more SDAF packages. FIGS. 41a 40 
to 41c are diagrams showing examples how to distribute 
the SDAF packages. In a distribution method as shown 
in FIG. 41a, a package 2301 includes only an audio 
content, while a package 2302 includes only an image 
or video graphic content. Moreover, from the package 45 
2302, the audio content included in the package 2301 is 
referred to. Therefore, the user who purchased only the 
package 2301 can play back only the audio content. 
The user who purchased the package 2302 in addition 
to the package 2301 can play back the graphic content so 
together with the audio content. As such, the SDAF title 
may be specified by adding a CEL to the existing track. 
[0167] In a distribution method as shown in FIG. 
41b, a package 2303 includes a plurality of audio con- 
tents and graphic contents. As such, a single package 55 
may include all CELs included in the SDAF title. 
[0168] In a distribution method as shown in FIG. 
41c, a single SDAF title is split into packages 2304, 



2305, and 2306 for distribution. The package 2305 
includes a content for Track #1 , while the package 2306 
includes a content for Track #2. In this distribution 
method, it is possible to select either one of the pack- 
ages 2305 and 2306 for distribution. 
[0169] Moreover, in the player, a new SDAF pack- 
age including a content owned by the user may be cre- 
ated. FIGS. 42a to 42c are diagrams showing examples 
how to create SDAF packages. In FIGS. 42a to 42c, a 
user package is an SDAF package created by the user, 
while a purchased package is a distributed SDAF pack- 
age. Contents surrounded by a thick line are owned by 
the user. It is assumed herein that the user owns data 
read from a CD, that is, an audio content ripped from the 
CD, and a graphic content created by himself/herself. 
[0170] As shown in FIG. 42a, the user may create a 
package 2401 including the audio content owned by 
himself/herself. Furthermore, as shown in FIG. 42b, the 
user may create a package 2402 including the audio 
and graphic contents owned by himself/herself. Still fur- 
ther, as shown in FIG. 42c, the user may create a pack- 
age 2404 from which the audio content included in the 
purchased package 2403 is referred to. If the package 
2404 is played back, the audio content included in the 
purchased package and the graphic content owned by 
the user are played back. Therefore, the image included 
in the purchased package can be changed to the image 
created by the user, or a new image created by the user 
can be added to the purchased package. 
[0171] Next, the SDAF-compliant DVD-Audio player 
for playing back the extended DVD-Audio disk is 
described. The player controls playback operation by 
following the navigation data described with SDAF 
instead of the original playback control information com- 
plying with the DVD-Audio standards. The player reads 
the navigation data and the CEL locator from the 
extended DVD-Audio disk, and operates by following 
the read navigation data. If the original audio content or 
image content is referred to from the navigation data, 
the player refers to the CEL locator to obtain information 
about the location in which the content is stored, and 
plays back the content. The player reads the back- 
ground image from the DVD-Audio region on the disk 
and the button images from the SDAF data, and com- 
bines them to display the menu screen. 
[0172] As such, with the use of the extended DVD- 
Audio disk, the existing DVD-Audio player can carry out 
conventional playback, while the SDAF-compliant DVD- 
Audio player can display the menu screen by using the 
navigation data described with SDAF. 
[0173] In the above description, the SDAF package 
and CEL redirector are stored in the disk. Alternatively, 
such data may be downloaded through a network to the 
player. This method can be applied to CDs and DVD 
disks that have already been sold to the user. Further- 
more, with this method, the CELs that are accessible 
through a communication network can be referred to by 
using the URL. 
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[0174] Next, a data conversion apparatus for copy- 
ing multimedia contents specified in SDAF to an exter- 
nal storage medium for portable music players is 
described. Here, the portable music player is structured 
by using semiconductor memory as an external storage 5 
medium, and characterized by its small size, light 
weight, and capability of writing data therein at high 
speed. The portable music player includes, as shown in 
FIG. 43, a liquid crystal display 2501 capable of display- 
ing text, a control panel 2502 for controlling audio play- 10 
back, and a headphone 2503 for audio output. 
Furthermore, a memory card 2500 for storing audio 
data can be removably attached to the portable music 
player. The portable music player plays back audio con- 
tents complying with MPEG2-AAC, and also displays 15 
text information. However, the data recording format of 
the memory card is not SDAF, but a unique format. 
[0175] FIG. 44 is a block diagram showing the 
structure of the data conversion apparatus for convert- 
ing contents recorded on an extended DVD-Audio disk 20 
into a predetermined format, and writing the converted 
contents in a memory card for portable music players. In 
FIG. 44, it is assumed that an LPCM-format audio con- 
tent, an image content in MPEG-I frame format, play- 
back control information described with SDAF, and 25 
additional text information are recorded in a disk 2601 . 
[0176] In the data conversion apparatus shown in 
FIG. 44, a data read unit 2602 reads the playback con- 
trol information from the disk 2601, and provides the 
same to a playback control information analyzing unit 30 
2603. The playback control information analyzing unit 
2603 analyzes the read playback control information to 
examine whether the content recorded on the disk 2601 
can be played back or requires conversion. 
[0177] Next, the data read unit 2602 sequentially 35 
reads, from the disk 2601, contents that can be played 
back by the portable music player, and provides the 
read contents to a data conversion unit 2605. At this 
time, contents that cannot be played back by the porta- 
ble music player is not read. The data conversion unit 40 
2605 converts the read contents according to the type 
of a memory card 2500. For example, text information 
that can be directly played back by the portable music 
player such as titles is not converted. On the other hand, 
LPCM-format audio contents are converted into 45 
MPEG2-AAC format so that the portable music player 
can play back the contents. 

[0178] The playback control information conversion 
unit 2604 generates playback control information for the 
portable music player based on the playback control so 
information analyzed by the playback control informa- 
tion analyzing unit 2603. A data write unit 2606 writes 
the playback control information generated by the play- 
back control information conversion unit 2604 and the 
contents converted by the data conversion unit 2605 in 55 
the memory card 2500. 

[0179] Note that, the data conversion unit shown in 
FIG. 44 may convert arbitrary contents other than audio 



contents into a predetermined format and write the con- 
verted contents in the memory card 2500. Furthermore, 
the data recording format of the memory card may be 
an arbitrary format other than SDAF. Still further, for 
supporting a plurality of external storage media, the 
data conversion apparatus may include the data conver- 
sion unit, playback control information conversion unit, 
and data write unit for each external storage medium. 
[0180] Moreover, if no navigation data described 
with SDAF is recorded on the disk 2601, as shown in 
FIG. 45, lacking data may be obtained through a com- 
munication network. In FIG. 45, it is assumed that an 
identification number is recorded in the disk 2601. For 
example, the identification number of a music CD is a 
catalog code, ISRC code, and others. 
[0181] The data read unit 2602 reads the identifica- 
tion number of the disk, and provides the same to a 
communication unit 2607. The communication unit 
2607 communicates with a content information server 
261 1 through a communication network 261 0. The com- 
munication unit 2607 may access to the content infor- 
mation server 261 1 through the Internet, or may directly 
access the content information server 2611 through a 
telephone circuit. The content information server 2611 
stores the lacking data in relation to the identification 
number, and in response to a request from a data con- 
version apparatus, sends the lacking data to the data 
conversion apparatus. After receiving the lacking data, 
the data conversion apparatus carries out the same 
operation as the data conversion apparatus as shown in 
FIG. 44. 

[0182] As stated above, the content distribution for- 
mat SDAF according to the present embodiment is a 
format for describing multimedia contents, and mainly 
used for music data distribution. Also, using the SDAF in 
combination with the existing music data can extend the 
function of the existing music data. 
[0183] Note that, as known from the comparison 
between FIGS. 3 and 18, the correlation between the 
music data described in the first to third embodiments 
and the SDAF according to the present embodiment is 
as follows. That is, the header 40 shown in FIG. 3 corre- 
sponds to the header 201 1 shown in FIG. 1 8. The navi- 
gation information 41 shown in FIG. 3 corresponds to 
the navigation data 2012 shown in FIG. 18. The content 
42 shown in FIG. 3 corresponds to the CEL 2013 shown 
in FIG. 18. The billing information 43 shown in FIG. 3 
corresponds to the offer 2014 shown in FIG. 18. 
[0184] While the invention has been described in 
detail, the foregoing description is in all aspects illustra- 
tive and not restrictive. It is understood that numerous 
other modifications and variations can be devised with- 
out departing from the scope of the invention. 

(Fourth Embodiment) 

[0185] As the fourth embodiment, as a specific 
example of copyrighted data as mentioned in the first to 
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third embodiments, a content distribution format called 
SDAF (Secure Digital Audio Format) is described below. 
Referring to FIGS. 18 to 39. details on the SDAF is first 
described, and then referring to FIGS. 40 to 45, how to 
use the SDAF is described. 5 
[0186] The content distribution format (SDAF) 
according to the present embodiment is used for 
describing multimedia contents that include audio, 
images, video, text, and file data. The multimedia con- 
tents described with SDAF are herein called an SDAF 10 
title. Presentation data each comprising the SDAF title 
is herein called a content element (hereinafter abbrevi- 
ated as CEL). Each CEL is assigned a CEL identifier 
that is unique in the SDAF title (hereinafter abbreviated 
as CELJD). 15 
[0187] The SDAF title is distributed as being split 
into units called SDAF packages. Each SDAF package 
is assigned a package identifier that is unique in the 
entire distribution system. FIG. 18 is a diagram showing 
an example of the SDAF package. As shown in FIG. 18, 20 
an SDAF title 2000 is composed of a plurality of SDAF 
packages. Each package 2001 is composed of a header 
2011, navigation data 2012, a plurality of CELs 2013, 
and an offer 2014. 

[0188] The header 2011 includes information such 25 
as location, size, and attribute of each data in the pack- 
age. Such information defines the package structure. 
The navigation data 2012 is playback control informa- 
tion specifying the operation of the player in playing 
back the SDAF title. From the navigation data 2012, a 30 
CEL included in the package to which the navigation 
data belong or in other packages is referred to. The CEL 
2013 is obtained by encrypting each presentation data 
composing the SDAF title, and more specifically, by 
encrypting audio, images, video, text, or file data. A pair 35 
of a decryption key for decrypting the CEL 2013 and 
CELJD is called a key pair. The offer 2014 includes a 
plurality of key pairs, and purchase rules describing the 
purchase price and available period for each key pair. 
[0189] FIGS. 19a to 19c are diagrams showing 40 
three types of SDAF packages. A full package 2001 
shown in FIG. 19c includes, similarly to FIG. 18, a 
header 2011, navigation data 2012, a plurality of CELs 
2013, and an offer 2014. An offer package 2002 shown 
in FIG. 19a includes the header 2011, the navigation 45 
data 2012, and the offer 2014, but does not include any 
CEL 2013. A CEL package 2003 shown in FIG. 19b 
includes the header 2011 and the plurality of CELs 
2013. Since the navigation data 2012 is required for 
playing back the SDAF title, the full package 2001 and so 
the offer package 2002 can be played back alone, but 
the CEL package 2003 cannot. 

[0190] The CEL package is used for splitting the 
SDAF title according to the distribution channel. For 
example, when distributed by using a CD-ROM, the 55 
SDAF title is recorded as a full package in the CD-ROM. 
On the other hand, when distributed through the Inter- 
net, the SDAF title is split into one full package and a 



plurality of CEL packages for distribution. For example, 
the SDAF title is split into one full package including an 
audio CEL and a plurality of CEL packages including a 
video CEL that is referred to from the full package for 
distribution. 

[0191] Further, as shown in FIG. 20, the SDAF title 
may be split into a plurality of SDAF packages by tracks. 
In package division as shown in FIG. 20, an SDAF title 
2020 including audio data for five tracks is split into 
three packages 2021 to 2023. The first to third pack- 
ages 2021 to 2023 have package names Single 1, 
Single2, and album, respectively. The first and second 
packages 2021 and 2022 both include an audio CEL for 
one track and navigation data for controlling playback of 
the CEL. The third package 2023 includes an audio 
CEL for three tracks and navigation data for controlling 
playback of all audio CELs included in the first to third 
packages 2021 to 2023. As such, by dividing the SDAF 
title into a plurality of SDAF packages, it is possible to 
make each data size smaller and easily handle each 
data. 

[0192] The header, offer, navigation data, and CEL, 
which compose the SDAF package, are described in 
this order below. 

[0193] The header 201 1 is first described. Here, an 
SDAF package shown in FIG. 21 is taken as an exam- 
ple, and a header 2031 of an SDAF package 2030 is 
described. In the SDAF package 2030, it is herein 
assumed that the size of navigation data 2032 and the 
size of an offer 2034 are 400H each, in hexadecimal 
notation. This package includes three CELs 2033, and 
the types thereof are, from first, audio, image, and file. It 
is assumed here in that the sizes of these CELs are, 
from first, 400000H, 18000H, and 8000H in hexadeci- 
mal notation. 

[0194] FIG. 22 is a diagram showing the structure of 
the header 2031 . In the header 2031 , data as described 
below is sequentially stored, and the size of the header 
is BCH in hexadecimal notation. Note that the structure 
of the header 2031 can be described in the C++ lan- 
guage as shown in FIGS. 23 and 24. FIGS. 23 and 24 
are a diagram showing a sequential source code as 
being split into two, and before division, a source code 
2062 shown in FIG. 24 follows a source code 2061 
shown in FIG. 23. 

[0195] At the start of the header 2031, a magic 
number 2041 (4 bytes) indicating that the file is in the 
SDAF format is stored. The value of the magic number 
2041 is a character string "SDAF". Then, a version 
number 2042 (4 bytes) of the SDAF is stored. Then, a 
package ID 2043 (16 bytes) and a package size 2044 (4 
bytes) are stored. Then, navigation data location infor- 
mation 2045 (SDAF_LOCATION_NAV in FIG. 23), offer 
location information 2046 (SDAF_LOCATlON_OFFER 
in FIG. 23), and the number of CELs in the package 
2047 are stored. Then, CEL information 2048 
(SDAF_LOCATION_CEL in FIG. 24) for each CEL is 
stored. Lastly, a CEL attribute table 2049 indicating an 
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attribute of each CEL is stored. 

[0196] The navigation data location information 
2045 indicates the location and size of the navigation 
data 2032. The offer location information 2046 indicates 
the location and size of the offer 2034. These two pieces 
of information are both composed of an offset (4 bytes) 
from the start of the SDAF package and each size (4 
bytes) thereof. 

[0197] The CEL information 2048 is composed of a 
CELJD 2051 (16 bytes), a CEL type 2052 (2 bytes), a 
CEL encryption type 2053 (2 bytes), a CEL data loca- 
tion information 2054, and a CEL attribute table location 
information 2055. The CELJD 2051 is a content ele- 
ment identifier that is unique in the SDAF title. The CEL 
type 2052 takes any value of audio, image, video, text, 
and file. The CEL encryption type 2053 indicates an 
algorithm used for encrypting the CEL. The CEL data 
location information 2054 and CEL attribute table loca- 
tion information 2055 are both composed of an offset (4 
bytes) from the start of the SDAF package and each 
size (4 bytes) thereof. If the offset or size is 0, that 
means no data exists. 

[0198] The CEL attribute table 2049 is a list of 
attributes specified for each CEL type. An audio CEL 
attribute table (S AD F_ATTR_ AUDIO in FIG. 24) 
includes at least CODEC, the number of quantized bits, 
sampling frequency, and the number of audio channels. 
An image CEL attribute table (SDAF_ATTR_GRAPHIC 
in FIG. 24) includes at least the height and width of the 
image and the encryption type. A video CEL attribute 
table includes at least the height and width of the video 
and the encryption type. A text attribute table includes at 
least the encryption type of the text, such as Unicode or 
music shift JIS (Japanese Industrial Standards). A file 
CEL attribute table includes at least the type of MIME 
(Multipurpose Internet Message Extension). 
[0199] The CEL attribute table 2049 is defined not 
as a fixed-length table but with a variable-length tag 
structure as shown in FIGS. 25a to 25c. If the tag struc- 
ture is used, a tag length and tag ID are stored preced- 
ing the data, as shown in FIG. 25a. For example, the 
image CEL attribute table is composed of a characteris- 
tic tag 2063 and an encryption type tag 2064. The table 
elements are specified by using the tag structure, 
thereby a new table element can be added to the data 
format or the data format can be changed only by add- 
ing a tag. The CEL attribute table is specified by using 
the tag structure with a great potential for expansion. 
[0200] Next, the offer 2014 is described. As stated 
above, the offer includes a plurality of key pairs and pur- 
chase rules for each key pair. Each key pair is com- 
posed of a decryption key for decrypting the CEL and a 
CELJD. FIG. 26 is a diagram showing the correspond- 
ence between the key pair and the CEL. As shown in 
FIG. 26, a key pair 2072 is composed of a decryption 
key 2073 and a CELJD 2074, and each key pair 2072 
is related to each CEL 2071 . The offer includes not only 
the key pair of the CEL included in the SDAF package 



but also all key pairs of the CELs included in the SDAF 
packages of the same SDAF title. In other words, when 
one SDAF title is split into a plurality of SDAF packages, 
only one SDAF package includes an offer, and this offer 
5 includes all key pairs of the CELs included in the SDAF 
title. 

[0201] The purchase rules are described by using a 
language for describing use conditions of the key pair, 
called right management language. The use conditions 

10 of the key pair include the date of purchase, use period, 
and whether a specific CEL or SDAF title has been pur- 
chased or not. The purchase rules are specified by 
using these use conditions, and thereby the same CEL 
can be sold at different prices depending on the condi- 

15 tions. 

[0202] Next, the navigation data 2012 is described. 
The navigation data is created by a content creator so 
that the user can use the CEL most effectively, defining 
the logic structure of the SDAF title. 

20 [0203] In SDAF, XML (extensible Markup Lan- 
guage), which is a tag description language in a text for- 
mat, is used for describing the navigation data. When 
the data structure is described in XML, a tag structure in 
a text format is used. Therefore, data described in XML 

25 is redundant compared with binary data. Nevertheless, 
XML is adopted because of its excellent expandability. 
[0204] To refer to the CEL from the navigation data, 
a CEL locator is used. The CEL locator is a concatena- 
tion of the package ID and CELJD taking '?' (question 

30 mark) as a delimiter. However, for the CEL included in 
the SDAF package that includes the navigation data, 
the package ID and the delimiter are omitted, and the 
CELJD becomes the CEL locator. The CEL locator can 
specify the CEL independently of the physical address 

35 of the CEL. 

[0205] FIG. 28 is a diagram how to refer to the CEL 
from the navigation data by using the CEL locator. In 
FIG. 28, navigation data 2081 and presentation data 

2082 are shown as an example. The presentation data 
40 2082 includes an audio CEL 2083 encoded with 

MPEG2-AAC and an image CEL 2084 encoded with 
JPEG. The package ID and CELJD of the audio CEL 

2083 are both 1, while those of the image CEL 2084 are 
1 and 2, respectively. In this case, a CEL locator "1?1" 

45 included in the navigation data 2081 indicates the audio 
CEL 2083 with its package ID "1" and CELJD 'T\ A 
CEL locator M 1?2" indicates the image CEL 2084 with its 
package ID "1" and CELJD "2". As known from this 
example, only a change in the package ID of the CEL 

so locator after creation of the SDAF title can cause a 
change in the structure of the SDAF package. There- 
fore, it is possible to structure the SDAF title as a single 
package or split the SDAF title into a plurality of SDAF 
packages. 

55 [0206] FIGS. 29 and 30 are diagrams showing the 
structure of the navigation data based on the following 
representation manner. Each rectangle represents an 
element of the navigation data. An arrow drawn from an 
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element A to an element B indicates that the element A 
includes the element B as a descendant element. Each 
mark provided at the start of each arrow indicates as fol- 
lows: * indicates that the element includes 0 or more 
descendant elements; + indicates that the element 5 
includes 1 or more descendant elements; and ? indi- 
cates that the element includes 0 or 1 descendant ele- 
ment. If the element A includes an item P without any 
arrow, that means the element A has the item P as an 
attribute. Underlined items represent CEL locators, w 
PCDATA represents a character string composed of 
characters included in a predetermined character set. 
This representation specifies a hierarchical structure 
with a TITLE element as a root. 

[0207] A TITLE element 2101 describes shipping 15 
information of the SDAF title. This element has three 
attributes: UPC, VERSION, and LANGUAGE. The UPC 
attribute describes a UPC (Universal Product Code), 
which is the international standards of product codes. 
The VERSION attribute describes the version number 20 
of the SDAF navigation structure. The LANGUAGE 
attribute describes the type of language according to 
ISO 639. Its default value is "en" indicating English. 
[0208] A METADATA element 2102 describes infor- 
mation such as genre of a PLAYLIST or TRACK ele- 25 
ment. The METADATA has a TYPE attribute. The TYPE 
attribute describes the type of the METADATA element. 
[0209] An ASSOC element 2103 describes refer- 
ence information to a CEL included in other SDAF title. 
This element has a REF attribute. The REF attribute 30 
describes the CEL locator. 

[0210] A URL element 2104 describes the URL 
(Uniform Resource Locator). This element has two 
attributes: ID and TYPE. The ID attribute describes the 
identification number of this element. The TYPE 35 
attribute describes the type of the URL element. 
[0211] A PLAYLIST element 2105 describes a play- 
list, which is a basic unit for the SDAF title. The playlist 
corresponds to an album in the conventional package 
media, and included in all SDAF titles. The PLAYLIST 40 
element may include a MENU element, which a menu 
for the playlist. The PLAYLIST element has five 
attributes: NAME, ARTIST, PRODUCTID, THUBMNAI- 
LID, and ONSTART. The NAME attribute describes the 
name of the playlist. The PRODUCTID attribute 45 
describes information corresponding to a catalog code 
in a CD. The THUMBNAILID attribute describes the 
CEL locator of the image CEL that is typical in the play- 
list. The ONSTART attribute describes the operation for 
playing back the playlist. If the ONSTART attribute is so 
"MENU", the player stops playing while displaying a 
playlist menu. If "TRACK", the player starts playing back 
the first TRACK element included in the PLAYLIST ele- 
ment. All PLAYLIST elements have at least one TRACK 
element 2106. 55 
[0212] The TRACK element 2106 describes the 
track including one audio. CEL. The TRACK element 
may include a track menu, slideshow, text, file, and oth- 



ers. The TRACK element has seven attributes: ID, 
NAME, ARTIST, ISRC, AUDIOID, TSMID. and THUM- 
BAILID. The ID attribute describes the identification 
number that is unique in the SDAF title. The NAME 
attribute describes the name of the TRACK element. 
The ARTIST attribute describes the name of the artist. 
The ISRC attribute describes ISRC (International 
Standard Recording Code). The AUDIOID attribute 
describes the CEL locator of the audio CEL related to 
the TRACK element. The TSMID attribute describes the 
CEL locator of a time search map corresponding to the 
audio CEL. The time search map will be described later. 
The THUMBNAILID attribute describes the CEL locator 
of the image CEL that is typical in the TRACK element. 
[0213] A MARKER element 2107 describes a 
marker for use in finding the start in the TRACK ele- 
ment. This element has two attributes: TIME and 
NAME. The TIME attribute describes the location of the 
marker in milliseconds. The NAME attribute describes 
the name of the marker. 

[0214] A SYNCSLIDESHOW element 2108 
describes a slideshow for displaying a slide or menu by 
following display timing information specified by a SYN- 
CMAP element 2109. The SYNCSLIDESHOW element 
2108 has three attributes: ID, NAME, and TYPE. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[021 5] The SYNCMAP element 21 09 describes the 
display timing information for the slide or the menu 
specified in the SYNCSLIDESHOW element. The SYN- 
CMAP element 2109 has three attributes: MENUID, 
PLAYID, and TIME. The MENUID attribute describes 
the identification number of the slide or menu to be dis- 
played. The PLAYID attribute describes the index 
number for specifying a button to be set in a playback 
state on the menu. The TIME attribute describes the 
display timing in milliseconds. 

[0216] A SLIDESHOW element 2110 describes the 
slideshow for displaying slides or menu at predeter- 
mined display intervals. This element has four 
attributes: ID, NAME, TYPE, and INTERVAL. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. The INTERVAL attribute describes the 
display interval of the slide or menu. 
[0217] A SYNCTEXT element 2111 describes text 
information to be displayed with predetermined timing. 
The text information is described by using a SYNC- 
TEXTBLOCK element 21 12. Alternatively, the text infor- 
mation may be specified by referring to part of the text 
CEL. The SYNCTEXT element has four attributes: ID, 
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TEXTID, REFID, and TYPE. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The TEXTID attribute describes the CEL locator of the 
text CEL. The REFID attribute describes the identifica- 
tion number of a TEXTREF element in the text CEL 5 
specified by the TEXTID attribute. The TEXTREF ele- 
ment will be described later. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 10 
[0218] The SYNCTEXTBLOCK element 2112 
describes the text information to be displayed with pre- 
determined timing. This element has a TIME attribute. 
The TIME attribute describes the display timing in milli- 
seconds. 15 
[0219] The TEXT element 21 13 describes text infor- 
mation. The text information is described in a text data 
format. Alternatively, the text information may be speci- 
fied by referring to part of the text CEL. The TEXT ele- 
ment has the same types of attributes as those of the 20 
SYNCTEXT element. 

[0220] A VIDEO element 21 14 describes any exist- 
ing video CEL. This element has three attributes: ID, 
VIDEOID, and TYPE. The ID attribute describes the 
identification number that is unique in the SDAF title. 25 
The VIDEOID attribute describes the CEL locator of the 
video CEL. The TYPE attribute describes the informa- 
tion category in the track, such as credits, lyrics, liner 
notes, biography, image collection, or promotion. 
[0221] A FILE element 21 15 describes any existing 30 
file CEL. This element has three attributes: ID, FILEID, 
and TYPE. The ID attribute describes the identification 
number that is unique in the SDAF title. The FILEID 
attribute describes the CEL locator of the file CEL. The 
TYPE attribute describes the information category in 35 
the track, such as credits, lyrics, liner notes, biography, 
image collection, or promotion. 

[0222] A SLIDE element 2116 describes a slide. 
This element has three attributes: ID, NAME, and 
BACKGROUNDID. The ID attribute describes the iden- 40 
tification number that is unique in the SDAF title. The 
NAME attribute describes the name of the slide. The 
BACKGROUNDID attribute describes the CEL locator 
of the image CEL on a slide screen. 

[0223] A MENU element 2117 describes a menu. 45 
The menu has one or more onscreen buttons. The 
MENU element has four attributes: ID, NAME, BACK- 
GROUNDID, and SELECTID. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The NAME attribute describes the name of the menu. 50 
The BACKGROUNDID attribute describes the CEL 
locator of the image CEL displayed on a menu screen. 
The SELECTID attribute describes the index number for 
specifying a button to be set in a select state. 
[0224] A BUTTON element 2118 describes the 55 
onscreen buttons arranged on the menu screen. The 
BUTTON element includes, as descendant elements, 
one or more pairs of TEXTBUTTON and COMMAND 



elements or those of GRAPH ICBUTTON and COM- 
MAND elements. The BUTTON element has seven 
attributes: INDEX, TAB, UP, DOWN, RIGHT, LEFT, and 
AUTOACTION. The INDEX attribute describes the 
number that is unique in the MENU element. The TAB 
attribute describes the sequential number sequentially 
provided for each of the buttons on the menu. The UP, 
DOWN, LEFT, and RIGHT attributes describe the index 
number of the selected destination button located 
upward, downward, leftward, and rightward, respec- 
tively, from the current button. The AUTOACTION 
attribute describes the flag indicating whether the state 
is automatically changed from select to active. 
[0225] The TEXTBUTTON element 2119 describes 
the onscreen button represented by text. This element 
has eleven attributes: X, Y, WIDTH, HEIGHT, FORN- 
TSIZE, NORMALCOLOR, SELECTCOLOR, ACTION- 
COLOR, PLAYINGCOLOR, TEXTID, and REFID. The 
X, Y, WIDTH, and HEIGHT attributes each describe the 
display location of the button using a coordinate system 
taking the upper-left corner of the menu as the origin. 
The FONTSIZE element describes the font size in 
points. The NORMALCOLOR, SELECTCOLOR, 
ACTIONCOLOR, and PLAYINGCOLOR attributes 
describe a display color in RGB format when the button 
state is normal, select, active, and playback, respec- 
tively. The TEXTID attribute describes the CEL locator 
of an external text CEL. The REFID attribute describes 
the identification number of the TEXTREF element in 
the text CEL specified by the TEXTID. 
[0226] The GRAPHICBUTTON element 2120 
describes the onscreen button represented as graphics. 
This element has eight attributes: X, Y, WIDTH, 
HEIGHT, NORMALID, SELECTID, ACTIONID, and 
PLAYINGID. The X, Y, WIDTH, and HEIGHT attributes 
each describe the display location of the button using a 
coordinate system taking the upper-left corner of the 
menu as the origin. The NORMALID, SELECTID, 
ACTIONID, and PLAYINGID attributes each describes 
the CEL locator of the image CEL displayed when the 
button state is normal, select, active, and playback, 
respectively. 

[0227] The COMMAND element 2121 describes 
the navigation operation when the user presses one of 
the onscreen buttons. This element has two attributes: 
TYPE and TARGET. The TYPE attribute describes any 
one of SHOW, FUNCTION, GOTO, NEXT, and PREVI- 
OUS commands. The SHOW command is for displaying 
the element specified by the TARGET attribute. The 
FUNCTION command is for executing the element 
specified by the TARGET attribute. This command is 
used while a playlist menu is being displayed. The 
GOTO command is for moving from the element cur- 
rently displayed to a specified brother element. The 
NEXT command is for moving from the element cur- 
rently displayed to the next brother element. The PRE- 
VIOUS element is for moving from the element currently 
displayed to the previous brother element. The TARGET 
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attribute describes the parameter of the command 
specified by the TYPE attribute. If the SHOW command 
is specified, the TARGET attribute describes the identi- 
fication number of the element to be displayed. If the 
FUNCTION command is specified, the TARGET 5 
attribute describes the identification number of the ele- 
ment to be executed. If the GOTO command is speci- 
fied, the TARGET attribute describes the identification 
number of the brother element of the element currently 
displayed. 10 
[0228] The TEXTREF element describes text cate- 
gory information for use in referring from the navigation 
data to part of the text data stored in the text CEL. The 
text data included in the TEXTREF element is referred 
to by specifying the identification number of the TEX- 15 
TREF element from the navigation data. The TEXTREF 
attribute has an ID attribute. The ID attribute describes 
the identification number that is unique in the SDAF 
tittle. 

[0229] Next, the CEL 2013 is described. The CEL 20 
has five types: an audio CEL, image CEL, video CEL, 
text CEL, and file CEL. In SDAF, the data format and 
parameter are specified for each type of the CEL. 
[0230] The data included in the audio CEL is audio 
data encoded as complying with MPEG2-AAC 25 
(Advanced Audio Coding) [Low Complexity Profile]. 
Note that MPEG2-AAC is specified in ISO/IEC 13818-7: 
1997(E) Information technology - Generic coding of 
moving pictures and associated audio information - 
Part7 Advanced Audio Coding (AAC). The bit stream 30 
encoded with MPEG2-AAC is assumed to be in the 
ADTS (Audio Data Transport Stream) format. Further, 
parameters described in ISO/IEC 13818-7 are 
restricted as shown in FIG. 31. Of these parameters, 
parameters other than sampling_frequency_index and 35 
channel_configuration are restricted due to selection of 
LC-profile specified by ISO/IEC 13818-7. Further, the 
average bit rate is 64 or 128 kbps. 
[0231] Data included in the image CEL is image 
data encoded as complying with JPEG, MPEG-I frame, 40 
PNG (Portable Network Graphics). FIGS. 32, 33 and 34 
are tables showing specification of JPEG, MPEG-I 
frame and PNG. The specifications for the encryption 
algorithms applied to the image CEL are restricted as 
shown in these drawings. 45 
[0232] Data included in the video CEL is video data 
encoded as complying with MPEG2. FIG. 35 is a table 
showing the specification of MPEG 2. The specification 
for the encryption algorithm applied to the video CEL is 
restricted as shown in FIG. 35. 50 
[0233] Data included in the text CEL is PLAIN text 
or XML text in SDAF. The encryption type is Unicode or 
music shift JIS. 

[0234] As an example of the file CEL, a time search 
map CEL that includes a time search map as data is 55 
now described. The time search map is a table com- 
posed of address of an audio frame. FIG. 36 is a dia- 
gram showing the structure of the time search map. As 
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shown in FIG. 36, a time search map 2090 is composed 
of a header 2091 and a plurality of entries 2092. FIGS. 
37, 38a, and 38b are a table and diagrams showing the 
header 2091 in detail. As shown in FIGS. 37, 38a, and 
38b, the header 2091 includes playback time between 
entries described in milliseconds and the total number 
of entries. FIG. 39 is a table showing each entry in 
detail. As shown in FIG. 39, each entry includes the 
address of the audio frame at its entry point. The first 
entry indicates the starting location of the audio frame 
included in the audio CEL. 

[0235] Note that in the present embodiment, 
MPEG2-AAC is used for compressing music data 
included in the audio CEL. Alternatively, MP3 (MPEG1 
Audio Layer 3), Dolby-AC3, or DTS (Digital Theater 
System) may be used. 

[0236] Next, with reference to FIGS. 40 to 45, how 
to use the SDAF is described. As stated above, the 
SDAF is a format for describing multimedia contents, 
and mainly used for music data distribution. The SDAF 
can be applied to various types of recording media, typ- 
ically hard disks, optical disks such as DVD-RAM, and 
semiconductor memory such as memory cards. 
[0237] In addition to music data distribution, the 
SDAF can be used in combination with the existing 
music data. For example, as will mentioned below, the 
SDAF can be used in combination with music data com- 
plying with the DVD-Audio standards. Similarly, the 
SDAF can be applied to other recording media such as 
DVD-Video, CD, Video-CD. and Photo CD. 
[0238] Music data complying with the DVD-Audio 
standards includes LPCM (Linear Pulse Code Modula- 
tion) audio contents and MPEG-I frame image contents. 
A player complying with the DVD-Audio standards dis- 
plays a menu screen for user's interactive operation. In 
the DVD-Audio standards, such menu screen is dis- 
played by superimposing a maximum of four sub video 
images onto a background image for display and provid- 
ing a plurality of rectangular regions in the sub video 
images. Such rectangular regions are called buttons, 
and each button is assigned a command. However, 
some restrictions are applied to the number of display 
colors and shape of the button and therefore the content 
creator cannot freely design the menu screen. 
[0239] This problem can be solved by previously 
recording data of the menu screen described in the 
SDAF in a conventional DVD-Audio disk, and displaying 
the menu screen using this data at playback. More spe- 
cifically, multimedia contents described in the SDAF and 
a CEL redirector for referring from the SDAF to the orig- 
inal DVD-Audio contents. Hereinafter, a DVD-Audio disk 
with such data recorded thereon is called an extended 
DVD-Audio disk, and a player for playing back the 
extended DVD-Audio disk is called SDAF-compliant 
DVD-Audio player. 

[0240] FIG. 40 is a diagram showing an example of 
the CEL redirectors that corresponds to a single DVD- 
Audio disk. Each row indicates the CEL redirector for 
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each content included in the original DVD-Audio disk. 
The CEL redirector includes a CELJD 2201, file name 
2202, start address 2203, and end address 2204. The 
CELJD 2201 is a content identifier that is unique in the 
disk. The file name 2202 is a name of the file that 5 
includes each content. The start and end addresses 
2203 and 2204 are offset values indicating the start 
location and end location, respectively, from each con- 
tent in the file. The CEL redirector is recorded in a file 
named DVDA.MAP, for example, in an SDAF directory 10 
provided in the ROM area of the extended DVD-Audio 
disk. 

[0241] All various playback control functions such 
as audio playback order control, slideshow image play- 
back, and a menu function defined by the DVD-Audio 15 
standards can be described using the SDAF navigation 
data. For example, the menu function can be realized by 
superimposing JPEG button images having any number 
of colors and shape onto an MPEG-I frame background 
image for display and relating each button region to a 20 
command. 

[0242] When playback control information included 
in the DVD-Audio disk is converted into SDAF naviga- 
tion data, information indicating a content is converted 
into the CELJD by using the CEL redirector. The menu 25 
screen is converted into JPEG button images. The 
obtained images are arranged at locations so as to be 
superimposed onto the background image. The naviga- 
tion data and button images as obtained in the above 
described manner are stored in a single SDAF package, 30 
and recorded in a file named SDAF.SDP, for example, in 
an SDAF directory provided in the ROM region of the 
extended DVD-Audio disk. The method of playing back 
the extended DVD-Audio disk will be described later. 
[0243] Next, an SDAF player for playing back multi- 35 
media contents described with SDAF is described 
below. The SDAF player plays back distributed music 
data in the following manner. First, the player searches 
for the package IDs and navigation information to collect 
the CELJDs of the CELs required for playback. The 40 
player searches purchase database using sets of the 
collected package ID and CELJD to determine whether 
each CEL has been purchased or not. If any CEL not 
yet purchased is found, the player analyzes the 
encoded offer, and pays a predetermined price through 45 
the existing electronic distribution system. After pur- 
chasing, the key pair stored in the offer is stored in the 
purchase database. If determining that the SDAF pack- 
age required for playback is not found in the player, the 
player sends out the package ID to the data distribution 50 
apparatus. The data distribution apparatus distributes 
an SDAF package with the received package ID to the 
player. After purchasing all CELs required for playback, 
the player decrypts the CELs using the key pairs stored 
in the purchase database for playback. At this time, the 55 
player interprets the navigation data for playback con- 
trol. 

[0244] The SDAF title is distributed to the player as 



being split into one or more SDAF packages. FIGS. 41a 
to 41 c are diagrams showing examples how to distribute 
the SDAF packages. In a distribution method as shown 
in FIG. 41a, a package 2301 includes only an audio 
content, while a package 2302 includes only an image 
or video graphic content. Moreover, from the package 
2302, the audio content included in the package 2301 is 
referred to. Therefore, the user who purchased only the 
package 2301 can play back only the audio content. 
The user who purchased the package 2302 in addition 
to the package 2301 can play back the graphic content 
together with the audio content. As such, the SDAF title 
may be specified by adding a CEL to the existing track. 
[0245] In a distribution method as shown in FIG. 
41b, a package 2303 includes a plurality of audio con- 
tents and graphic contents. As such, a single package 
may include all CELs included in the SDAF title. 
[0246] In a distribution method as shown in FIG. 
41c, a single SDAF title is split into packages 2304, 
2305, and 2306 for distribution. The package 2305 
includes a content for Track #1 , while the package 2306 
includes a content for Track #2. In this distribution 
method, it is possible to select either one of the pack- 
ages 2305 and 2306 for distribution. 
[0247] Moreover, in the player, a new SDAF pack- 
age including a content owned by the user may be cre- 
ated. FIGS. 42a to 42c are diagrams showing examples 
how to create SDAF packages. In FIGS. 42a to 42c, a 
user package is an SDAF package created by the user, 
while a purchased package is a distributed SDAF pack- 
age. Contents surrounded by a thick line are owned by 
the user. It is assumed herein that the user owns data 
read from a CD, that is, an audio content ripped from the 
CD, and a graphic content created by himself/herself. 
[0248] As shown in FIG. 42a, the user may create a 
package 2401 including the audio content owned by 
himself/herself. Furthermore, as shown in FIG. 42b, the 
user may create a package 2402 including the audio 
and graphic contents owned by himself/herself. Still fur- 
ther, as shown in FIG. 42c, the user may create a pack- 
age 2404 from which the audio content included in the 
purchased package 2403 is referred to. If the package 
2404 is played back, the audio content included in the 
purchased package and the graphic content owned by 
the user are played back. Therefore, the image included 
in the purchased package can be changed to the image 
created by the user, or a new image created by the user 
can be added to the purchased package. 
[0249] Next, the SDAF-compliant DVD-Audio player 
for playing back the extended DVD-Audio disk is 
described. The player controls playback operation by 
following the navigation data described with SDAF 
instead of the original playback control information com- 
plying with the DVD-Audio standards. The player reads 
the navigation data and the CEL locator from the 
extended DVD-Audio disk, and operates by following 
the read navigation data. If the original audio content or 
image content is referred to from the navigation data, 
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the player refers to the CEL locator to obtain information 
about the location in which the content is stored, and 
plays back the content. The player reads the back- 
ground image from the DVD-Audio region on the disk 
and the button images from the SDAF data, and com- 5 
bines them to display the menu screen. 
[0250] As such, with the use of the extended DVD- 
Audio disk, the existing DVD-Audio player can carry out 
conventional playback, while the SDAF-compliant DVD- 
Audio player can display the menu screen by using the 10 
navigation data described with SDAF. 
[0251] In the above description, the SDAF package 
and CEL redirector are stored in the disk. Alternatively, 
such data may be downloaded through a network to the 
player. This method can be applied to CDs and DVD 15 
disks that have already been sold to the user. Further- 
more, with this method, the CELs that are accessible 
through a communication network can be referred to by 
using the URL. 

[0252] Next, a data conversion apparatus for copy- 20 
ing multimedia contents specified in SDAF to an exter- 
nal storage medium for portable music players is 
described. Here, the portable music player is structured 
by using semiconductor memory as an external storage 
medium, and characterized by its small size, light 25 
weight, and capability of writing data therein at high 
speed. The portable music player includes, as shown in 
FIG. 43, a liquid crystal display 2501 capable of display- 
ing text, a control panel 2502 for controlling audio play- 
back, and a headphone 2503 for audio output. 30 
Furthermore, a memory card 2500 for storing audio 
data can be removably attached to the portable music 
player. The portable music player plays back audio con- 
tents complying with MPEG2-AAC, and also displays 
text information. However, the data recording format of 35 
the memory card is not SDAF, but a unique format. 
[0253] FIG. 44 is a block diagram showing the 
structure of the data conversion apparatus for convert- 
ing contents recorded on an extended DVD-Audio disk 
into a predetermined format, and writing the converted 40 
contents in a memory card for portable music players. In 
FIG. 44, it is assumed that an LPCM-format audio con- 
tent, an image content in MPEG-I frame format, play- 
back control information described with SDAF, and 
additional text information are recorded in a disk 2601 . 45 
[0254] In the data conversion apparatus shown in 
FIG. 44, a data read unit 2602 reads the playback con- 
trol information from the disk 2601, and provides the 
same to a playback control information analyzing unit 
2603. The playback control information analyzing unit so 
2603 analyzes the read playback control information to 
examine whether the content recorded on the disk 2601 
can be played back or requires conversion. 
[0255] Next, the data read unit 2602 sequentially 
reads, from the disk 2601, contents that can be played 55 
back by the portable music player, and provides the 
read contents to a data conversion unit 2605. At this 
time, contents that cannot be played back by the porta- 



ble music player is not read. The data conversion unit 
2605 converts the read contents according to the type 
of a memory card 2500. For example, text information 
that can be directly played back by the portable music 
player such as titles is not converted. On the other hand, 
LPCM-format audio contents are converted into 
MPEG2-AAC format so that the portable music player 
can play back the contents. 

[0256] The playback control information conversion 
unit 2604 generates playback control information for the 
portable music player based on the playback control 
information analyzed by the playback control informa- 
tion analyzing unit 2603. A data write unit 2606 writes 
the playback control information generated by the play- 
back control information conversion unit 2604 and the 
contents converted by the data conversion unit 2605 in 
the memory card 2500. 

[0257] Note that, the data conversion unit shown in 
FIG. 44 may convert arbitrary contents other than audio 
contents into a predetermined format and write the con- 
verted contents in the memory card 2500. Furthermore, 
the data recording format of the memory card may be 
an arbitrary format other than SDAF. Still further, for 
supporting a plurality of external storage media, the 
data conversion apparatus may include the data conver- 
sion unit, playback control information conversion unit, 
and data write unit for each external storage medium. 
[0258] Moreover, if no navigation data described 
with SDAF is recorded on the disk 2601 , as shown in 
FIG. 45, lacking data may be obtained through a com- 
munication network. In FIG. 45, it is assumed that an 
identification number is recorded in the disk 2601. For 
example, the identification number of a music CD is a 
catalog code, ISRC code, and others. 
[0259] The data read unit 2602 reads the identifica- 
tion number of the disk, and provides the same to a 
communication unit 2607. The communication unit 
2607 communicates with a content information server 
261 1 through a communication network 261 0. The com- 
munication unit 2607 may access to the content infor- 
mation server 261 1 through the Internet, or may directly 
access the content information server 2611 through a 
telephone circuit. The content information server 2611 
stores the lacking data in relation to the identification 
number, and in response to a request from a data con- 
version apparatus, sends the lacking data to the data 
conversion apparatus. After receiving the lacking data, 
the data conversion apparatus carries out the same 
operation as the data conversion apparatus as shown in 
FIG. 44. 

[0260] As stated above, the content distribution for- 
mat SDAF according to the present embodiment is a 
format for describing multimedia contents, and mainly 
used for music data distribution. Also, using the SDAF in 
combination with the existing music data can extend the 
function of the existing music data. 
[0261] Note that, the correlation between the super 
distribution data described in the first and second 
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embodiments and the SDAF according to the present 
embodiment is as follows. That is, the additional infor- 
mation including reproduction control information as to 
the image data and audio data in the second embodi- 
ment corresponds to the navigation data 2012 shown in 5 
FIG. 18. The content 205 or audio data 204 shown in 
FIG. 2 and the image data in the second embodiment 
correspond to the CEL 2013 shown in FIG. 18. The right 
management information 203 shown in FIG. 2 corre- 
sponds to the offer 2014 shown in FIG. 18. 10 
[0262] While the invention has been described in 
detail, the foregoing description is in all aspects illustra- 
tive and not restrictive. It is understood that numerous 
other modifications and variations can be devised with- 
out departing from the scope of the invention. 15 

Claims 

1 . A digital data copyright protection system for charg- 
ing a user appropriate royalties while protecting a 20 
copyright of digital data, the system comprising: 

a content distribution unit (102) operable to dis- 
tribute super distribution data including said 
digital data over a network (104): 25 
a plurality of digital data recording and repro- 
ducing apparatuses (1011, 1012, and 1013) 
interconnected via said network (104), each 
capable of storing the super distribution data 
received from said content distribution unit 30 
(102), reproducing said digital data, and distrib- 
uting said super distribution data stored therein 
to the others; and 

a billing processing unit (103) operable to com- 
municate with said digital data recording and 35 
reproducing apparatuses (1011, 1012, and 
1013) over said network (104), and go through 
a billing processing for charging said royalties, 
wherein 

said digital data recording and reproducing 40 
apparatuses (1011, 1012, and 1013) each 

communicate, prior to reproducing said 
digital data, with said billing processing 
unit (103) to go through a purchase 45 
processing to be ready for said billing 
processing when receiving the super distri- 
bution data from said content distribution 
unit (102) or the other digital data record- 
ing and reproducing apparatuses over said so 
network (104), and 

add, prior to distribution, a distributor ID to 
the super distribution data received from 
said content distribution unit (102) or the 
other digital data recording and reproduc- 55 
ing apparatuses over said network (104), 
wherein, 



when the super distribution data subjected to 
the billing processing is provided with said dis- 
tributor ID, said billing processing unit (103) 
goes through a bonus processing with respect 
to a user identified by the distributor ID. 

2. A digital data recording and reproducing apparatus 
(1011) being capable of storing super distribution 
data including a content which is digital data 
encrypted under a first system and right manage- 
ment information having a content key used for said 
first system, and of reproducing said content after 
going through a purchase processing to be ready 
for a billing processing by communicating with a bill- 
ing processing unit (103) connected via a network 
(104), the apparatus comprising: 

super distribution data receiving means (401) 
operable to externally receive said super distri- 
bution data; 

super distribution data storage means (402) 
operable to store said super distribution data; 
purchase processing means (412) operable to 
go through, in response to a user's instruction, 
said purchase processing to reproduce the 
content included in the super distribution data 
stored in said super distribution data storage 
means (402); 

data accessing means (410) operable to 
extract said super distribution data from said 
super distribution data storage means (402); 
content decrypting means (414) operable to 
decrypt, when said purchase processing is car- 
ried out, the super distribution data stored in 
said super distribution data storage means 
(402) under said first system, and extract said 
content; 

reproduction means (415 and 416) operable to 
reproduce the content extracted by said con- 
tent decrypting means (414); and 
distributor ID adding means (411) operable to 
encrypt a first user ID which is identification 
information unique to the apparatus, and add 
the encrypted first user ID to the super distribu- 
tion data extracted by said data accessing 
means (410) for external output. 

3. The digital data recording and reproducing appara- 
tus according to claim 2, wherein said right man- 
agement information is also encrypted under a 
second system, and 

a right management information key used for 
said second system is stored in a secured 
region where no user is accessible in a normal 
manner. 

4. The digital data recording and reproducing appara- 
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tus (1011) according to claim 2. wherein said dis- 
tributor ID adding means (411) comprises: 

management information acquiring means 
(504) operable to acquire a state of purchase 5 
indicating whether or not the purchase 
processing has been carried out by said pur- 
chase processing means (412); 
user ID acquiring means (501) operable to 
acquire said first user ID stored in a secured 10 
region where no user is accessible in a normal 
manner; 

user ID encrypting means (502) operable to 
add, to the first user ID acquired by said user ID 
acquiring means (501), the state of purchase is 
acquired by said management information 
acquiring means (504) for encryption under a 
predetermined system; and 
user ID adding means (503) operable to add 
the first user ID encrypted by said user ID 20 
encrypting means (502) to the super distribu- 
tion data extracted by said data accessing 
means (410). 

5. The digital data recording and reproducing appara- 25 
tus (1011) according to claim 2, wherein said pur- 
chase processing means (412) comprises: 

billing control information extracting means 

(602) operable to extract billing control informa- 30 
tion from the super distribution data extracted 

by said data accessing means (410); 
distributor ID extracting means (603) operable 
to extract a second user ID if included in the 
super distribution data extracted by said data 35 
accessing means (410); 

billing processing information generating 
means (604) operable to add, if any second 
user ID is extracted by said distributor ID 
extracting means (602), said second user ID to 40 
the billing control information extracted by said 
billing control information extracting means 

(603) , and generate billing processing informa- 
tion; 

billing processing information transmitting 45 
means (605) operable to transmit the billing 
processing information generated by said bill- 
ing processing information generating means 

(604) to the billing processing unit (103), which 

is externally provided; and 50 
transmitter ID transmitting means (606) opera- 
ble to transmit said first user ID as the transmit- 
ter ID to the externally provided billing 
processing unit (103). 

55 

6. The digital data recording and reproducing appara- 
tus (1011) according to claim 2, further comprising: 



data reading means (406) operable to read a 
content which is unencrypted digital data; 
right management information acquiring 
means (403) operable to acquire right manage- 
ment information having the content key for 
encrypting the content read by said data read- 
ing means (406); 

content key extracting means (405) operable to 
extract said content key from the right manage- 
ment information acquired by said right man- 
agement information acquiring means (403); 
data encrypting means (408) operable to 
encrypt said content under said first system 
with the content key extracted by said content 
key extracting means (405); and 
right management information adding means 
(409) operable to add the corresponding right 
management information to the content 
encrypted by said data encrypting means (408) 
for storage in said super distribution data stor- 
age means (402). 

7. The digital data recording and reproducing appara- 
tus (1011) according to claim 6, further comprising 
data compressing means (407) operable to com- 
press the content read by said data reading means 
(406) in a predetermined manner, and input the 
compressed content into said data encrypting 
means (408). 

8. The digital data recording and reproducing appara- 
tus (1011) according to claim 6, further comprising 
additional information storage means (1703) opera- 
ble to store content reproduction control information 
including information as to control content repro- 
duction and image data added as content; and 

data adding means (1702) operable to add said 
content reproduction information and said 
image data stored in said additional information 
storage means (1703) to the corresponding 
content for output to said data encrypting 
means (408). 

9. A billing processing unit (103) operable to store 
super distribution data, and from a digital data 
recording and reproducing apparatus (1011, 1012, 
or 1013) capable of reproducing a content after a 
billing processing, receive, over a network(104), 
billing control information corresponding to said 
super distribution data, a distributor ID indicating 
who has distributed said super distribution data, 
and a transmitter ID corresponding to said digital 
data recording and reproducing apparatus (1011, 
1012, or 1013), the billing processing unit compris- 
ing: 

billing processing information receiving means 
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54 



(802) operable to receiving said billing control 
information and said distributor ID; 
transmitter authorizing means (803) operable 
to receive said transmitter ID and identify a 
transmitter; 5 
billing processing means (804) operable to 
carry out, according to the billing control infor- 
mation received by said billing processing infor- 
mation receiving means (802), the billing 
processing with respect to the transmitter iden- w 
tifted by said transmitter authorizing means 

(803) ; and 

bonus processing means (808) operable to 
carry out a bonus processing for a distributor 
identified by the distributor ID received by said 15 
billing processing information receiving means 
(802). 



a purchase processing step of carrying out the 
billing processing to reproduce the content 
included in said super distribution data 
responding to a user's instruction; 
a content decrypting step of, when the billing 
processing is carried out in said purchase 
processing step, decrypting said super distribu- 
tion data under said first system, and extracting 
said content; 

a reproducing step of reproducing the content 
extracted in said content decrypting step; and 
a distributor ID adding step of encrypting a first 
user ID which is unique identification informa- 
tion, and adding the first user ID to said super 
distribution data for output. 



10. A digital data recording and reproducing method of 
storing super distribution data including a content 20 
which is digital data encrypted under a first system 
and right management information having a content 
key used for said first system, and of reproducing 
said content after a billing processing, the method 
comprising: 25 



a super distribution data receiving step of 
externally receiving said super distribution 
data; 

a purchase processing step of carrying out the 30 
billing processing to reproduce the content 
included in said super distribution data 
responding to a user's instruction; 
a content decrypting step of, when the billing 
processing is carried out in said purchase 35 
processing step, decrypting said super distribu- 
tion data under said first system, and extracting 
said content; 

a reproducing step of reproducing the content 
extracted in said content decrypting step; and 40 
a distributor ID adding step of adding, respond- 
ing to the user's instruction, a first user ID 
which is unique identification information to 
said super distribution data for output. 

45 

11. A computer readable/writable recording medium 
being recorded a program to be executed on a com- 
puter system capable of storing super distribution 
data including a content which is digital data 
encrypted under a first system and right manage- so 
ment information having a content key used for said 
first system, and of reproducing said content after a 
billing processing, the program achieving a method 
comprising: 

55 

a super distribution data receiving step of 
externally receiving said super distribution 
• data; 
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typedef struct SDAF ATTR GRAPHIC PROPS 
{ - - - 

enum { TAG_ID = 0x0001 } ; 
SDAF_ATTR width; 
SDAF_ATTR height; 
SDAF_ATTR bitDepth; 
} SDAF_ATTR_GRAPHIC_PROPS; 

typedef struct SDAF ATTR GRAPHIC CODEC; 
{ - _ _ 

enum { TAG_ID = 0x0002 } ; 
SDAF_ATTR codec; // 0: JPEG, etc 

SDAF_ATTR compression; // 0: RLE, 1:LZW, etc 
} SDAF_ATTR_GRAPHIC_CODEC ; 
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